Watchdog microservice to resolve locks when processing fails on a transaction exchange platform

ABSTRACT

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. As the transactions are processed, the transactions may require access to a resource (e.g., a key value in a database). A microservice processing the transaction may request, from a locking microservice, a lock for the resource. The locking microservice may query a local cache to determine whether a lock exists for the resource. If the local cache determines that no lock exists for resource, the locking mechanism may employ a consensus protocol to obtain a lock for the resource from a plurality of clusters. If consensus is reached, a lock for the resource may be granted to the requesting microservice.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. application Ser. No.17/389,045, filed on Jul. 29, 2021 and entitled “Transaction ExchangePlatform with Watchdog Microservice,” which is a continuation of U.S.application Ser. No. 16/723,545 (now U.S. Pat. No. 11,080,120), filed onDec. 20, 2019 and entitled “Transaction Exchange Platform with WatchdogMicroservice,” the entireties of which are incorporated herein byreference.

This application is related to the following U.S. patent applications,filed on the same day:

-   -   Attorney Docket No. 009033.00489, entitled “Consensus Key        Locking with Fast Local Storage for Idempotent Transactions” and        filed concurrently herewith; and    -   Attorney Docket No. 009033.00590, entitled “Regenerating        Transaction Objects When Processing Fails On A Transaction        Exchange Platform” and filed concurrently herewith.        Each of the related applications is incorporated by reference        herein in its entirety for all purposes.

FIELD OF THE INVENTION

Aspects of the disclosure relate generally to a transaction exchangeplatform. More specifically, aspects of the disclosure may provide formanaging locks when resources are accessed from geographically disparateregions. Additional aspects of the disclosure may provide for resolvinglocks when processing of transaction objects that hold the lock for aresource fail.

BACKGROUND OF THE INVENTION

Computer systems and applications have revolutionized the handling oftransactions and greatly accelerated clearing and settlement processes.Software solutions have been created to facilitate processing,validation, and approval of transactions. These systems serve tointerface transaction originators with clearing and settlementoperations, allowing transactions to flow between enterprises andfacilitating the movement of trillions of dollars per year. However,some transactions handled by the transaction exchange platform areextremely sensitive to duplicate data. Because of this, the transactionexchange platform must guarantee idempotent transactions have theability to lock a key, resource, and/or data, across all instances, inall regions. Existing solutions suffer from shortcomings that cannotguarantee idempotent transactions. For example, traditional writeforward mechanisms, such as Redis Active-Active, have a window wherecross-region writes eventually become consistent and could allowinstances in both regions to believe that they own the lock, resultingin the potential for duplicate processing. Furthermore, existingdatabase solutions are unable to guarantee idempotent transactions havethe ability to lock a key, resource, and/or data, across all instances,in all regions. In this regard, relational databases, such as AWS Aurora(MySQL Multi-mater), have performance issues with frequent conflictresolution, which is to be expected when processing replicated streamingdata in multiple regions. Other databases, like Cockroach DB, etcd,RedisRaft, and the like, may offer consensus protocol solutions, likeRaft, which may provide a locking mechanism. However, these otherdatabases may attempt to version each update, which would requireconsensus overhead that would increase latency. Additionally oralternatively, these other databases may allow subsequent changes to bemade provided there was not a simultaneous write conflict. Anotherproblem is that these other databases tend to hold a limited amount ofdata due to the synchronization of snapshots. Moreover, the databasesthat implement consensus protocols traditionally solve for a singleinstance lock acquisition and are, therefore, relatively slow and unableto scale. Accordingly, existing database solutions that use theconsensus protocol for all read and write transactions would incur toomuch overhead and latency to be able to function effectively in aproduction environment.

Aspects described herein may address these and other shortcomingspresent in existing solutions. Novel aspects discussed herein mayimplement a transaction exchange platform using a streaming dataplatform and microservices to provide faster, more dynamic, and morerobust processing and approval of transactions. The novel transactionexchange platform may provide benefits such as improving the flexibilityand reliability of transaction approval and processing systems, whileoffering robust record keeping for transaction audit purposes. The novelplatform may also provide other benefits such as support for legacy andongoing operations, solving for new and changing requirements in today'senvironment, and adapting to future technologies

SUMMARY OF THE INVENTION

The following presents a simplified summary of various aspects describedherein. This summary is not an extensive overview, and is not intendedto identify key or critical elements or to delineate the scope of theclaims. The following summary merely presents some concepts in asimplified form as an introductory prelude to the more detaileddescription provided below.

Aspects described herein may relate to a locking mechanism that enableslock acquisition consensus across a geographically distributedtransaction exchange platform. The locking mechanism may leverage aconsensus protocol only when acquiring a lock on a key value and handlesall other aspects of data access with a local fast write forward system.This is an improvement over existing systems since leveraging consensusprotocol only when acquiring a lock on a key value, and handling allother aspects of data access with a fast write forward system,guarantees idempotent transactions in a system with data replicatedacross regions. By limiting the consensus protocol interactions only towriting unique keys—which is done once per transaction, the lockingmechanism improves performance by storing metadata and/orapplication-related state details in the local cache system after thelock is acquired. This further improves the performance and reliabilityof the distributed locking mechanism.

Corresponding apparatus, systems, and computer-readable media are alsowithin the scope of the disclosure.

These features, along with many others, are discussed in greater detailbelow.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example and not limitedin the accompanying figures in which like reference numerals indicatesimilar elements and in which:

FIG. 1 depicts an example of a computing device that may be used inimplementing one or more aspects of the disclosure in accordance withone or more illustrative aspects discussed herein;

FIG. 2 depicts an example operating environment used to discussillustrative aspects of a transaction exchange platform according to oneor more aspects of the disclosure;

FIG. 3A depicts an example transaction exchange platform according toone or more aspects of the disclosure;

FIGS. 3B-3C depict example structures for microservices according to oneor more aspects of the disclosure;

FIG. 4 depicts an illustrative workflow as a directed acyclic graphaccording to one or more aspects of the disclosure;

FIG. 5 depicts an illustrative method for processing transactions on astreaming data platform according to one or more aspects of thedisclosure;

FIG. 6 depicts an example transaction exchange platform having aconfiguration interface according to one or more aspects of thedisclosure;

FIGS. 7A-7C depict illustrative changes to workflows, as graphs,according to one or more aspects of the disclosure;

FIG. 8 depicts an illustrative method for reconfiguring microservicesaccording to one or more aspects of the disclosure;

FIG. 9 depicts an example transaction exchange platform having asnapshot microservice and a watchdog microservice according to one ormore aspects of the disclosure;

FIGS. 10-15 depict illustrative methods for operation of the snapshotmicroservice and the watchdog microservice according to one or moreaspects of the disclosure;

FIG. 16 depicts an example of a transaction exchange platform accordingto one or more aspects of the disclosure;

FIG. 17 depicts an example of a method for obtaining a lock on aresource according to one or more aspects of the disclosure;

FIG. 18 depicts an example of a method for releasing a lock on aresource according to one or more aspects of the disclosure;

FIGS. 19A and 19B depict an example of a method for resolving a lockwhen processing of a transaction that owns the lock fails according toone or more aspects of the disclosure; and

FIG. 20 depicts an example of a flowchart illustrating an example methodfor determining to replay a transaction on a transaction exchangeplatform according to one or more aspects of the disclosure.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference ismade to the accompanying drawings, which form a part hereof, and inwhich is shown by way of illustration various embodiments in whichaspects of the disclosure may be practiced. It is to be understood thatother embodiments may be utilized and structural and functionalmodifications may be made without departing from the scope of thepresent disclosure. Aspects of the disclosure are capable of otherembodiments and of being practiced or being carried out in various ways.Also, it is to be understood that the phraseology and terminology usedherein are for the purpose of description and should not be regarded aslimiting. Rather, the phrases and terms used herein are to be giventheir broadest interpretation and meaning. The use of “including” and“comprising” and variations thereof is meant to encompass the itemslisted thereafter and equivalents thereof as well as additional itemsand equivalents thereof.

By way of introduction, aspects described herein may relate to atransaction exchange platform using a streaming data platform andmicroservices to process transactions according to review and approvalworkflows. A transaction exchange platform, according to one or moreaspects discussed herein, may provide a version agnostic data streaming,reactive microservice solution that facilitates payment relatedworkflows to be executed. Although the term “microservice” is usedthroughout this disclosure, aspects are not limited to “microservices”as used in cloud computing contexts. Generally, as used herein“microservice” may refer to a technology process that does work on anobject on a streaming data platform in any given step of a workflow.Aspects discussed herein may refer to “approval” of transactions. Thisgenerally refers to the processing necessary to move a transactionthrough the transaction exchange platform from intake to output, anddoes not necessarily mean that the payment exchange platformaffirmatively approves the nature of the transaction. Instead,“approval” as used herein may refer to processing, validating, and/oraffirmatively approving a transaction according to a workflow indicatingthe steps necessary to process a transaction on the platform before itis ready for output to downstream processors.

Before discussing these concepts in greater detail, however, severalexamples of a computing device that may be used in implementing and/orotherwise providing various aspects of the disclosure will first bediscussed with respect to FIG. 1 .

FIG. 1 illustrates one example of a computing device 101 that may beused to implement one or more illustrative aspects discussed herein. Forexample, computing device 101 may, in some embodiments, implement one ormore aspects of the disclosure by reading and/or executing instructionsand performing one or more actions based on the instructions. In someembodiments, computing device 101 may represent, be incorporated in,and/or include various devices such as a desktop computer, a computerserver, a mobile device (e.g., a laptop computer, a tablet computer, asmart phone, any other types of mobile computing devices, and the like),and/or any other type of data processing device.

Computing device 101 may, in some embodiments, operate in a standaloneenvironment. In others, computing device 101 may operate in a networkedenvironment. As shown in FIG. 1 , various network nodes 101, 105, 107,and 109 may be interconnected via a network 103, such as the Internet.Other networks may also or alternatively be used, including privateintranets, corporate networks, LANs, wireless networks, personalnetworks (PAN), and the like. Network 103 is for illustration purposesand may be replaced with fewer or additional computer networks. A localarea network (LAN) may have one or more of any known LAN topology andmay use one or more of a variety of different protocols, such asEthernet. Devices 101, 105, 107, 109 and other devices (not shown) maybe connected to one or more of the networks via twisted pair wires,coaxial cable, fiber optics, radio waves or other communication media.

As seen in FIG. 1 , computing device 101 may include a processor 111,RAM 113, ROM 115, network interface 117, input/output interfaces 119(e.g., keyboard, mouse, display, printer, etc.), and memory 121.Processor 111 may include one or more computer processing units (CPUs),graphical processing units (GPUs), and/or other processing units such asa processor adapted to perform computations associated with machinelearning. I/O 119 may include a variety of interface units and drivesfor reading, writing, displaying, and/or printing data or files. I/O 119may be coupled with a display such as display 120. Memory 121 may storesoftware for configuring computing device 101 into a special purposecomputing device in order to perform one or more of the variousfunctions discussed herein. Memory 121 may store operating systemsoftware 123 for controlling overall operation of computing device 101,transaction exchange platform software 125 for instructing computingdevice 101 to perform aspects discussed herein, machine learningsoftware 127, smart database 129, and other applications 131. Machinelearning software 127 may be incorporated in and may be a part oftransaction exchange platform software 125. In embodiments, computingdevice 101 may include two or more of any and/or all of these components(e.g., two or more processors, two or more memories, etc.) and/or othercomponents and/or subsystems not illustrated here.

Devices 105, 107, 109 may have similar or different architecture asdescribed with respect to computing device 101. Those of skill in theart will appreciate that the functionality of computing device 101 (ordevice 105, 107, 109) as described herein may be spread across multipledata processing devices, for example, to distribute processing loadacross multiple computers, to segregate transactions based on geographiclocation, user access level, quality of service (QoS), etc. For example,devices 101, 105, 107, 109, and others may operate in concert to provideparallel computing features in support of the operation of control logic125 and/or software 127.

One or more aspects discussed herein may be embodied in computer-usableor readable data and/or computer-executable instructions, such as in oneor more program modules, executed by one or more computers or otherdevices as described herein. Generally, program modules includeroutines, programs, objects, components, data structures, etc. thatperform particular tasks or implement particular abstract data typeswhen executed by a processor in a computer or other device. The modulesmay be written in a source code programming language that issubsequently compiled for execution, or may be written in a scriptinglanguage such as (but not limited to) HTML or XML. The computerexecutable instructions may be stored on a computer readable medium suchas a hard disk, optical disk, removable storage media, solid statememory, RAM, etc. As will be appreciated by one of skill in the art, thefunctionality of the program modules may be combined or distributed asdesired in various embodiments. In addition, the functionality may beembodied in whole or in part in firmware or hardware equivalents such asintegrated circuits, field programmable gate arrays (FPGA), and thelike. Particular data structures may be used to more effectivelyimplement one or more aspects discussed herein, and such data structuresare contemplated within the scope of computer executable instructionsand computer-usable data described herein. Various aspects discussedherein may be embodied as a method, a computing device, a dataprocessing system, or a computer program product.

Having discussed several examples of computing devices which may be usedto implement some aspects as discussed further below, discussion willnow turn to methods and techniques for implementing a transactionexchange platform.

Transaction Exchange Platform—Processing Streaming Transaction DataUsing Microservices

Aspects described herein may provide a transaction exchange platformimplemented using a streaming data platform (SDP) and a plurality ofmicroservices to process transactions according to workflowscorresponding to different transaction types. Microservices on thetransaction exchange platform may be configured to retrieve transactionshaving a current workflow stage that is assigned to the microservicefrom the SDP. The microservice may perform one or more steps of theapproval/review workflow for the type of transaction, update the statusof the object, and put it back to the SDP. Other microservices, later inthe workflow, may see that the current workflow status of a transactionindicates that earlier pre-requisite processing steps have completed andmay accordingly retrieve the transaction objects and perform theirrespective workflow steps. When the current workflow stage of atransaction indicates that all requisite steps of the workflow have beencompleted, the transaction may be removed from the SDP of thetransaction exchange platform and output to downstream systems forfurther processing.

A high level system 200 for processing transactions, such as payments,is illustrated in FIG. 2 . Transaction processing system 200 may broadlyillustrate the flow of transactions from origination source 205 throughto settlement systems 220. Transactions handled by system 200 may takeany suitable form, generally as payment transactions. Example types ofpayment transactions include: wires, automated clearing house (ACH)payments, checks, cashier checks, real-time payments (RTP), creditcards, and/or many other types of payment transactions. Other factorsthat may inform the “type” of a transaction may include whether thetransaction originates domestically or internationally, whether thedestination is domestic or international, an amount of the transaction,the identity of one or more financial entities associated with thetransaction, and the like. For purposes of the discussion herein, atransaction type may be relevant primarily for informing thereview/approval steps that should be applied to the transaction prior tofinal settlement.

Transactions may begin at origination sources 205. For example, if acustomer were to purchase a donut at a bakery using a credit card, thetransaction may be sent via a point-of-sale (POS) terminal at the bakeryto a payment processor. As another example, an investor may cause a wirepayment to be sent to their broker via a banking website. The bankingwebsite may receive the wire payment transaction and begin the processof facilitating settlement of the wire transaction via a transactionprocessing system 200.

Transactions may be routed to settlement systems 220 to effect thetransfer of the monies indicated in the transaction. For example, thewire transaction may be routed to respective financial institutionsassociated with the investor and broker to indicate the respectivedebit/credit to their accounts. However, substantial review and approvalprocessing may be required before a transaction may be settled. Thisprocessing may involve regulatory, security, and/or risk management.

Transaction exchange platform 210 may serve as an interface between theorigination source 205 and settlement systems 220, and according to someaspects may implement the transaction review and approval workflow foreach supported transaction type. Origination sources 205 may sendtransactions to transaction exchange platform 210 for review andapproval processing, and ultimately for routing to settlement systems220. Transaction exchange platform 210 may be provided by the sameentity operating settlement systems 220 and/or one or more oforigination sources 205, or may be provided by a third-party entity.

Transaction exchange platform 210 may perform the review and approvalprocessing for transactions. This may include interfacing with clearingsystems 215. Clearing systems 215 may provide regulatory, security,and/or risk management support for transactions. For example,transactions may be referred to systems provided by the U.S. FederalReserve as part of a clearance process. As another example, theidentities of the parties to the transaction may need to be evaluatedagainst various criteria in support of anti-money laundering or othersuch efforts. Clearing systems 215 may be provided as part oftransaction exchange platform 210, or as logically separate systems.Clearing systems 215 may be provided by the entities operatingorigination sources 205, transaction exchange platform 210, settlementsystems 220, government entities, and/or other third parties.

Transaction exchange platform 210 may interface with clearing systems215 to complete review and approval processing on the transaction.Transactions that are approved on transaction exchange platform 210 maybe routed to settlement systems 220 for settlement and/or furtherprocessing.

FIG. 3A illustrates a system 300 that may provide further details of anovel transaction exchange platform 320 than provided in FIG. 2 ,according to some aspects described herein. Similarly, transactions mayoriginate at transaction origination sources 303 and route to downstreamsettlement systems, illustrated in FIG. 3A as enterprise systems andusers 350.

Transaction exchange platform 320 may serve to perform review andapproval workflow processing on transactions received from transactionorigination sources 303 via enterprise transaction intermediary services305. Transaction origination sources 303 may include both first- andthird-party sources of transactions. The enterprise providingtransaction exchange platform 320 may provide transaction intermediaryservices 305 to receive transactions, whether from third-parties or not,and route those transactions to transaction exchange platform 320.Enterprise transaction intermediary service 305 may perform validation,pre-processing, standardization, and/or any other suitable processing toprepare transactions for further handling by transaction exchangeplatform 320.

Transactions may be sent to transaction exchange platform 320 viaapplication programming interfaces (APIs), such as API 311 and API 313.The APIs may validate aspects of the transaction details, and maypackage and/or standardize transactions into transaction objectssuitable for processing on transaction exchange platform 320. In someimplementations, transaction exchange platform 320 may provide differentAPIs for each type of transaction. For example, API 311 may correspondto ACH transactions while API 313 corresponds to wire transactions. Insome implementations, fewer APIs (such as a single centralized API) maybe used to flexibly validate and initialize transactions for processingby transaction exchange platform 320. The APIs for interfacing withtransaction exchange platform 320 may comprise a number of components,such as a public API front-end, basic input validation logic, messagelevel integrity processes, monitoring, and/or integration aspects.

Transaction objects may be pushed to a streaming data platform (SDP) 325underlying transaction exchange platform 320. Streaming data platforms,such as those based on the Apache Kafka open-source platform, may beused to process real-time data in computer systems. Message objectspushed to the streaming data platform may be read by consumer softwaremodules, processed, and put back to the streaming data platform.Transaction objects on SDP 325 may be subject to processing bymicroservices on transaction exchange platform 320, such as microservice331, microservice 332, and microservice 333. The microservices can readand write transaction objects from/to SDP 325. Objects on SDP 325 mayproceed logically through time, e.g. t₀ through t_(n), as they progressthrough stages of the workflow associated with a correspondingtransaction type.

Transaction objects, such as transaction object 307, may includetransaction details, addenda, and transaction metadata. The transactiondetails and/or addenda may include the particulars of the transaction,such as the parties and/or accounts involved, as well as the amount ofthe payment. Addenda data of the transaction object may include, e.g.,ABA routing numbers and other details that may be added, updated, and/orprocessed by the microservices on transaction exchange platform 320. Thetransaction metadata may include at least an indication of a workflowcorresponding to a transaction type of the transaction object and acurrent workflow stage of the transaction object. In someimplementations, discussed further herein, the transaction metadata mayalso include workflow version information.

As an example, transaction object 307 may include the following:

{  transaction ID : a SHA256 encoded token  workflow type : ACH  currentworkflow stage : init  transaction details : ISO20022 token  addendadata { ABA routing : xyz } }Transaction object 307 may encapsulate any suitable standard paymentobject, such as one storing transaction details in a recognized JSONformat. As mentioned, and as illustrated further in FIG. 6 , transactionobjects may also include a current workflow version assigned to thetransaction object. Still other metadata may be included, such as areplay tracking count indicating the number of times that thetransaction has been subject to replay through one or more steps of theworkflow. Transaction details may be immutable, not subject to changewhile the transaction object is on the streaming data platform, whereasmetadata and/or addenda data may be subject to change through additions,removals, updates, and/or other processing or modification by themicroservices on transaction exchange platform 320.

A current workflow stage value may be maintained as part of thetransaction metadata in each transaction object. The current workflowstage may indicate which processing steps of the associated workflowhave been completed on the transaction. The current workflow stage mayindicate the completion status of each respective step of the workflow.As such, in an example implementation the current workflow stage valuemay be a set of values and/or a data structure indicating the completionof individual workflow steps, e.g. processing by respectivemicroservices. Microservices may be configured to poll the SDP fortransactions having a current workflow stage value that indicatescompletion of each of the pre-requisite steps for processing by themicroservice.

Microservices on the transaction exchange platform may poll the SDP toidentify and retrieve transaction objects having a current workflowstage matching a workflow stage associated with the microservice.Transaction objects matching the microservice's assigned workflow stagemay be processed by the microservice for review, approval, and/or anyother suitable processing as part of the overall series of stepsrequired to approve a transaction of the corresponding transaction type.Processing may result in updating one or more elements of thetransaction metadata. Once the microservice completes its processing ofthe transaction object, the microservice can put the transaction objectback to the SDP with an updated current workflow stage indicating thatthe microservice completed its processing. The updated transactionobject may then be identified and processed by a next microservice basedon the workflow.

Turning briefly to FIGS. 3B and 3C, FIG. 3B illustrates an examplestructure for a microservice 330N. The microservice may comprisesubcomponents configured to work in concert to apply processing logicassociated with a workflow step assigned to the microservice. In theillustrated structure, microservice 330N comprises a stream listener3301 which may operate as a standardized way to read from SDP 325 andconsume transaction objects that meet the workflow criteria (e.g.,stage) associated with microservice 330N. Microservice 330N may alsoinclude private API 3302, which may be a RESTful implementation used insynchronous calls supporting singleton integrations into transactionexchange platform 320, and its use may allow only the response to beexposed to the public API aspect of microservice 330N. Microservice 330Nmay also include core logic 3303, which may contain the business logicand associated computer instructions to fulfill microservice 330N'sassigned role in the workflow. Core logic 3303 may be adapted to processtransaction objects in accordance with one or more steps of regulatory,security, and/or risk management processes. Microservice 330N mayfurther include transient data 3304, which may include a data managementlayer that deals with data that is attributed to the local functionalityof the system, for example truth tables used in processing by core logic3303, and persistent data 3307, which may include a construct to capturestate data for the associated workflow stage. Microservice 330N mayfurther include messaging components 3305 to track message levelintegrity via natural key encryption derivations of the payment object.And microservice 330N may include monitoring components 3306, configuredto provide oversight and tracking, and integration components 3308,configured to provide the ability to integrate with software structurepatterns such as Async SDP, SOAP, RESTful API, and the like. Asillustrated in FIG. 3C, however, a microservice may be made up of acollection of other microservices. For example, as illustratedmicroservice 331N comprises component microservices 3321, 3322, and3323.

Returning to FIG. 3A, illustrative transaction exchange platform 320includes three microservices (microservices 331, 332, and 333)configured to operate on ACH transactions. Transaction object 307 is anexample ACH transaction, and is added to SDP 325 via API 311.Transaction object 307 may be added to SDP 325 in an “init” orinitialization stage, indicating that none of the workflow steps haveyet been completed. In some implementations, the initialization stagemay be a separate stage that is marked completed prior to processing bya first microservice, or may be commensurate in scope with a firstworkflow stage associated with a first microservice of the workflow. Insome implementations, the initialization stage for the object may behandled as part of the processing by the APIs 311, 313 or otherwisehandled alongside workflow processing by the respective microservices.

Walking through the example, transaction object 307 may be added to SDP325 in the initialization stage (stage ‘0’). Microservice 331 may beconfigured to perform a first step in an approval workflow fortransaction having a transaction type of ACH. For example, microservice331 may be configured to verify that the recipient account of the ACHtransaction is valid. Microservice 331 may look for transaction objectson SDP 325 having a first workflow stage (stage ‘1’), for example astage that indicates initialization pre-processing was completed or, insome implementations, transaction objects in the initialization stageitself. As mentioned above, the current workflow stage of transactionobject 307 may indicate each (and/or a subset) of the workflow stepsthat have been completed on transaction object 307, and the currentworkflow stage thus may comprise a data structure listing the completionstatus of each (and/or a subset) of the workflow steps. Microservice 331may poll SDP 325 to retrieve transaction objects having a currentworkflow stage matching (e.g., meeting) the first workflow stageassigned to microservice 331. In this manner, microservice 331 mayextract transaction objects from SDP 325 that have met the criteria formicroservice 331 to begin processing. For example, microservice 331 maybe configured to wait until initialization steps such as new objectsnapshotting is completed before performing its processing to verify therecipient account. Transaction objects retrieved by microservice 331 maybe removed and/or otherwise blocked on SDP 325 pending processing bymicro service 331.

Microservice 331, having retrieved one or more transaction objects suchas transaction object 307, may perform its corresponding workflow stepon the transaction object. The workflow step may comprise suitableprocessing of the transaction object, such as according to core logic ofmicroservice 331 (similar to core logic 3303 of FIG. 3B). Processing ofthe transaction object by microservice 331 (or any other microservice)may comprise any of: retrieving the transaction object; reviewing valuesand other characteristics of the transaction object; interfacing withclearing systems such as clearing systems 215 and/or other systems;comparing values or characteristics to rules, regulations, policies, andthe like; adding, removing, updating, or otherwise changing any aspectof the transaction addenda data or transaction metadata; generatingreports and/or alerts; presenting the transaction for manual or otherreview; and/or any other suitable processing associated with therespective step of the workflow for transactions of that type. Forexample, processing by a microservice may comprise verifying a value ofthe transaction details, addenda data, and/or transaction metadataagainst at least one rule. As another example, processing may compriseverifying a value of the transaction details, addenda data, and/ortransaction metadata against a watchlist. Processing may comprisedetermining that the transaction details, addenda data, and/ortransaction metadata fail at least one rule; flagging the transactionobject for further review; and holding the transaction object in thecurrent workflow stage pending the further review, where updating thecurrent workflow stage of the transaction object to the third workflowstage is based on determining that the further review is completed.Flagging the transaction object for further review may comprise flaggingthe transaction object for manual review by a user and/or setting thecurrent workflow stage of the transaction object to a current workflowstage associated with another microservice, other than the microservicethat typically processes transactions after the first microservice.

The processed transaction object may be put back to SDP 325 bymicroservice 331, and the current workflow stage of the transactionobject may be updated to indicate that microservice 331 has completedits processing. For example, transaction object 307 may be updated tohave a current workflow stage of ‘2’ after microservice 331 completesits processing.

Back on the SDP 325, the updated transaction object may be subject tofurther processing by other microservices in like fashion. For example,microservice 332 may correspond to a second step of processing in theworkflow corresponding to ACH transactions, such as a regulatory checkassociated with anti-money laundering efforts. Microservice 332 may beconfigured to look for transaction objects having a second currentworkflow stage, e.g., stage ‘2’, on SDP 325. Microservice 332 can pollSDP 325 to retrieve such transaction objects and process them accordingto its own core logic, similarly to that described above with respect tomicroservice 331. The processed transaction object may be put back tothe SDP 325 with an updated current workflow stage indicating thatprocessing by microservice 332 is completed. Microservice 333 may beconfigured to look for a third current workflow stage, e.g. stage ‘3’,and may process transaction objects similarly. For example, microservice333 could perform processing to obligate a customer's account for thevalue of the transaction.

When the current workflow stage of a transaction object indicates it hascompleted the steps of the corresponding workflow, the transactionobject may be removed from SDP 325 and routed or otherwise madeavailable to other components of the overall transaction system. Forexample, the approved transaction object, having passed through allsteps of the corresponding workflow, may be published to a publicstreaming data platform 340 accessible outside of the transactionexchange platform. Enterprise systems, applications, users, and others(e.g. enterprise services and users 350) may access the completedtransaction objects on the public streaming data platform and furtherprocess for transaction settlement or other purposes.

The structure described herein, where microservices poll SDP 325 fortransaction objects having corresponding current workflow stages, maydrive payments and other transactions through the system and requisitereview and approval workflows. As mentioned, the workflow for a giventransaction type may comprise a plurality of processing steps requiredto approve a given transaction of the transaction type. Workflows may beimplemented in the configurations of what workflow stage metadata eachmicroservice is configured to look for on the SDP 325. However,workflows may also be logically described and/or defined using adirected acyclic graph structure, as described further with respect toFIG. 4 .

FIG. 4 illustrates a sample directed acyclic graph (DAG) 400 that maycorrespond to a workflow corresponding to transactions having a wiretransaction type. The steps of the workflow corresponding to a giventransaction type may be organized as a DAG. The DAG may comprise nodescorresponding to the individual steps of the workflow, and edgescorresponding to pre-requisite relationships between the steps. The DAGmay indicate how transactions from an origination source such asorigination 410 flow through the transaction exchange platform 320,until approval is completed and the transaction is ready for furtherprocessing by downstream systems. The DAG may include parallel paths,whereby the transaction object may be subject to concurrent processingby multiple microservices. The DAG may indicate pre-requisite conditionsthat govern the progression of the transaction object through the stagesof the workflow. For example, processing by a microservice in the DAGmay be conditioned on the completion of processing by one or more othermicroservices. The DAG may also indicate branching, conditional pathswhere a transaction object may be subject to processing by differentmicroservices (and/or different processing generally) based on certaintransaction attributes.

In the example workflow for wire transactions 400 illustrated in FIG. 4, a transaction object added to transaction platform 320 fromorigination 410 may first enter step ‘A’. Step ‘A’ may correspond to amicroservice that performs processing to verify that a recipient accountin the transaction details and/or addenda is valid. Once step ‘A’processing is complete, the workflow proceeds to step ‘B’, which maycorrespond to a high value thresholder that operates to splittransactions for different processing based on their value (alsoimplemented as a microservice). For example, once step ‘A’ is completedand a first microservice updates the current workflow stage of thetransaction object, a microservice associated with step ‘B’ may pick upthe transaction object and determine if it involves a payment over acertain value, e.g., payments more than $5000. The microserviceassociated with step ‘B’ may update the transaction object withdifferent current workflow stages depending on whether the transactionshould be subject to high value processing (e.g., step ‘C’) or standardprocessing (e.g., step ‘D’). Step ‘C’ may occur subsequent to step ‘B’determining that a high value transaction should be subject to enhancedverification, and may comprise performing the enhanced verification by acorresponding microservice. Step ‘D’ may comprise performing standardregulatory verification by a corresponding microservice. Step ‘D’ mayalso determine if the transaction is an international or domestic wire,and may update the current workflow stage and/or other transactionmetadata accordingly. If the transaction is an international wire, itmay be routed (by means of the updated transaction metadata) to amicroservice associated with step ‘E’, which may perform furtherinternational wire processing. If the transaction is a domestic wire, itmay proceed to step ‘F’ once regulatory checks are completed. Step ‘F’may comprise a step to obligate the customer's account for the amount ofthe wire, and may be conditioned on successful completion of steps ‘C’,‘D’, or ‘E’ depending on how the transaction progressed through theworkflow. For example, a microservice corresponding to step ‘F’ may beconfigured to poll SDP 325 for transactions having a current workflowstage that indicates they have completed steps ‘C’, ‘D’, or ‘E’.Finally, completing the workflow step ‘G’ may correspond to amicroservice configured to send the wire transaction for settlement,such as to settlement systems 220 of FIG. 2 or enterprise services andusers 350 of FIG. 3A. Having completed workflow step ‘G’, thetransaction metadata may be updated to indicate completion of theworkflow. For example, the current workflow stage of the transactionobject may be updated to indicate completion of step ‘G’. As anotherexample, the current workflow stage of the transaction object mayreflect the completion of each of steps ‘A’, 13′, ‘D’, ‘F’, and ‘G’.

Workflow 400 is just one example of a workflow corresponding to atransaction type, and the transaction exchange platform 320 may havemany such workflows corresponding to different transaction types.Microservices on transaction exchange platform 320 may be involved inone or more workflows, and may operate on different stages of differentworkflows.

Workflow steps may proceed in parallel, and may be independent of one ormore other steps in the workflow. For example, if validating the accountnumber of the sending party and validating the account number of thereceiving party were handled by different microservices, the workflowmay indicate that both may occur once the transaction is brought ontothe platform. However, later steps may be conditioned on the completionof both steps. Either step may occur first in time, depending on theavailability of each respective microservice to handle the transaction.

Microservices on transaction exchange platform 320 may be automaticallyconfigured to look for a corresponding current workflow stage. Thisautomatic configuration may be based on the DAG structure used tologically define the workflow. For example, the individual microservicesmay be automatically configured to poll SDP 325 for transactions havinga current workflow stage that indicates that the pre-requisite criteriarepresented in the DAG is met prior to processing by the microservice.Each microservice may be configured to look for transaction objects onSDP 325 that have a given workflow type and also have a current workflowstage matching that assigned to the microservice. Thus, microservicesmay be configured to operate as part of multiple workflows, and can lookfor transaction objects at different stages of the workflows. Asdiscussed further herein with respect to FIG. 6 , changes to the DAG maybe used to automatically re-configure the microservices to watch fortransaction objects in different workflows and/or different workflowstages.

FIG. 5 depicts a flowchart illustrating an example method 500 to processtransactions by a transaction exchange platform, such as transactionexchange platform 320. Method 500 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 500.

At step 505, the system may configure microservices on the transactionexchange platform to watch for transactions of the streaming dataplatform (SDP) that have transaction metadata indicating that they arein a current workflow stage corresponding to the individualmicroservice. As discussed above with respect to FIG. 4 , the system mayautomatically configure the microservices based on a DAG structure thatlogically defines the steps of the workflow and their relationships.

At step 510, the system may receive a transaction object and add it tothe streaming data platform. The transaction object may be received froma transaction origination source such as origination source 303, and maybe received from an enterprise intermediary service, such as enterprisetransaction intermediary service 305. The transaction object may bereceived via one or more APIs of the transaction exchange platform, suchas APIs 311 and 313 of transaction exchange platform 320. Thetransaction object may be added to the SDP in an initialization stage,which may be implemented through setting a current workflow stage of thetransaction object's transaction metadata to an initialization value.The initialization stage may be separate from a first workflow stageassociated with a first microservice of the workflow, or could be thesame as the first workflow stage. Objects in the initialization stagemay be subject to various system processes on the transaction exchangeplatform, such as format or other verifications, standardization,snapshots, and the like. If the initialization stage is separate from afirst workflow stage of the workflow, the transaction object may beupdated to have the first workflow stage once initialization processingis completed.

The transaction object, on the SDP, may be subject to processing by oneor more microservices including first microservice 520 and secondmicroservice 530. First microservice may be configured to poll the SDPfor transactions in a first workflow stage, while second microservicemay be configured to poll the SDP for transactions in a second workflowstage.

At step 521, first microservice 520 may poll the SDP for transactionshaving a particular workflow type (corresponding to a transaction type)and having a first workflow stage within that workflow corresponding tofirst microservice 520. The SDP may identify transaction objects thathave a current workflow stage value that matches the first workflowstage criteria associated with the first microservice 520.Identification of matching transaction may be based on transactionmetadata indicating a type of workflow, a current workflow stage, andother information associated with the workflow (such as workflow versioninformation, discussed below with respect to FIG. 6 ). At step 523,first microservice 520 may retrieve the matching transaction objects forprocessing. Although steps 521 and 523 are illustrated separately, itwill be understood that in practice they may be part of a singlecontiguous act.

At step 525, first microservice 520 may process the transaction objectsit retrieved from the SDP according to processing logic associated withfirst microservice 520. Processing a transaction object may include:reviewing, assessing, analyzing, updating, adding to, removing, and/orany other suitable processing of the transaction data, addenda data,and/or transaction metadata associated with the transaction object.

At step 527, first microservice 520 may update a current workflow stageof the transaction object to indicate completion of the processingcorresponding to first microservice 520. In some embodiments, thecurrent workflow stage may be updated to different next step valuesdepending on the processing by first microservice 520. For example, asdiscussed with respect to workflow 400 in FIG. 4 , a microservice mayupdate the current workflow stage of a transaction object to route it todifferent next microservices depending on whether it meets certaincriteria, such as having a value greater than a threshold amount.

At step 529, first microservice 520 may put the updated transactionobject back to the SDP. The updated transaction object may have one ormore changed values (or none) of its transaction data, addenda data,and/or transaction metadata, in addition to the updated current workflowstage.

In the example of method 500, first microservice 520 may update thecurrent workflow stage of the transaction object to indicate completionof processing by the first microservice 520. This updated currentworkflow stage may correspond to the second current workflow stage thatsecond microservice 530 is looking for on the SDP.

Thus, at step 531, the second microservice 530 may poll the SDP fortransactions having the second workflow stage and, at step 533, mayretrieve transaction objects matching the second workflow stage. Thesecond microservice 530 may perform similar processing to that describedabove with respect to first microservice 520. That is, steps 531, 533,535, 537, and 539 may be analogous to steps 521, 523, 525, 527, and 529,modified as appropriate for the role assigned to second microservice 530in the workflow for a given transaction type. The processed, updatedtransaction object may be put back to the SDP with an updated currentworkflow stage indicating completion of the processing corresponding tosecond microservice 530.

At step 540, the system may determine that the current workflow stagemetadata of the transaction object indicates that all requisiteprocessing steps of the workflow have been completed. As a result,processing by the transaction exchange platform may be completed and theapproved transaction object may be removed from the SDP and output forfurther processing and/or settlement. For example, as illustrated inFIG. 3A, a completed, approved transaction may be output to a public SDPfor access by downstream systems and users.

Thus, according to some embodiments a computer-implemented method mayreceive a transaction object comprising transaction details andtransaction metadata. That transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The computer-implemented method may furthercomprise adding the transaction object to a streaming data platform andupdating the current workflow stage of the transaction object to a firstworkflow stage. A first microservice may poll the streaming dataplatform to retrieve transactions matching the first workflow stage. Thefirst workflow stage may be associated with the first microservice basedon the workflow corresponding to the transaction type. The firstmicroservice may retrieve, from the streaming data platform, thetransaction object based on the current workflow stage matching thefirst workflow stage. The first microservice may process the transactionobject. The computer-implemented method may further comprise updatingthe current workflow stage of the transaction object to a secondworkflow stage based on completing processing, by the firstmicroservice, of the transaction object. A second microservice may pollthe streaming data platform to retrieve transactions matching the secondworkflow stage. The second workflow stage may be associated with thesecond microservice based on the workflow corresponding to thetransaction type. The second microservice may retrieve, from thestreaming data platform, the transaction object based on the currentworkflow stage matching the second workflow stage. The secondmicroservice may process the transaction object. Thecomputer-implemented method may further comprises updating the currentworkflow stage of the transaction object to a third workflow stage basedon completing processing, by the second microservice, of the transactionobject; determining that the current workflow stage of the transactionobject indicates that the transaction object has completed processingcorresponding to the workflow; and removing the transaction object fromthe streaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

The first and second microservice may be automatically configured towatch for transactions on the streaming data platform in the first andsecond workflow stages, respectively, based on the plurality ofprocessing steps. A different second workflow may be associated with asecond transaction type and may comprise a different second plurality ofprocessing steps required to approve a given transaction of the secondtransaction type. The second transaction type may be different from thetransaction type. The first microservice may operate on transactionsassociated with both the workflow and the different second workflow. Theplurality of processing steps of the workflow may indicate that thefirst microservice processes the transaction object at a different stagethan the different second plurality of processing steps of the differentsecond workflow.

The workflow corresponding to the transaction type may comprise adirected acyclic graph (DAG) indicating the plurality of processingsteps required to approve a given transaction of the transaction type.The first and second microservice may be automatically configured towatch for transactions on the streaming data platform in the first andsecond workflow stages, respectively, based on the DAG. Thecomputer-implemented method may further comprise, responsive to anupdate to at least one of the plurality of processing steps indicated inthe DAG, automatically reconfiguring at least one microservice based onthe update.

The current workflow stage of the transaction object may comprise a datastructure indicating completion status of each respective step of aplurality of processing steps associated with the workflow. Thetransaction object may be updated to have a current workflow stagecorresponding to the second workflow stage based on the current workflowstage indicating that the transaction object has been processed by atleast the first microservice and a different third microservice. Thefirst workflow stage and a fourth workflow stage may be independent,such that a third microservice receives the transaction object based onthe current workflow stage of the transaction object matching the fourthworkflow stage irrespective of whether the first microservice hasprocessed the transaction object.

The transaction details may be immutable and may not change while thetransaction object is on the streaming data platform. The processing, bythe first microservice, of the transaction object may comprise verifyinga value of the transaction details, addenda data, and/or transactionmetadata against at least one rule. Processing of the transaction objectby the first microservice may comprise verifying a value of thetransaction details, addenda data, and/or transaction metadata against awatchlist. Processing of the transaction object by the secondmicroservice may comprise determining that the transaction details,addenda data, and/or transaction metadata fail at least one rule,flagging the transaction object for further review, and holding thetransaction object in the second workflow stage pending the furtherreview. Updating the current workflow stage of the transaction object tothe third workflow stage may be based on determining that the furtherreview is completed. Flagging the transaction object for further reviewmay comprise flagging the transaction object for manual review by auser. Flagging the transaction object for further review may comprisesetting the current workflow stage of the transaction object to a fourthworkflow stage associated with a third microservice. Updating thecurrent workflow stage of the transaction object to the third workflowstage may be based on determining that processing by the thirdmicroservice is completed.

As examples, the transaction type of the transaction object may be awire type transaction. The workflow may comprise a plurality ofprocessing steps required to approve a wire transaction. The transactiontype of the transaction object may be an automated clearing house (ACH)type transaction. The workflow may comprise a plurality of processingsteps required to approve an ACH transaction. The transaction type ofthe transaction object may be a cashier check type transaction. Theworkflow may comprise a plurality of processing steps required toapprove a cashier check transaction. The first microservice may processthe transaction object to validate a routing number associated with thetransaction object. The second microservice may process the transactionobject to verify compliance with at least one regulatory requirementassociated with the transaction type. The transaction object may bereceived via an application programming interface (API).

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice and a second microservice. The first andsecond microservice may be automatically configured to watch fortransactions on the streaming data platform in corresponding workflowstages based on a plurality of workflows corresponding to a plurality oftransaction types. The memory may store instructions that, when executedby the at least one processor, cause the platform to receive atransaction object comprising transaction details and transactionmetadata. The transaction metadata may comprise an indication of aworkflow corresponding to a transaction type of the transaction objectand a current workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to approve a given transaction of thetransaction type. The instructions, when executed by the at least oneprocessor, may further cause the platform to add the transaction objectto the streaming data platform; update the current workflow stage of thetransaction object to a first workflow stage; and poll, by the firstmicroservice, the streaming data platform to retrieve transactionsmatching the first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The instructions, when executedby the at least one processor, may further cause the platform toretrieve, by the first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the first workflow stage; process, by the first microservice,the transaction object to add, remove, or update addenda data associatedwith the transaction object; update the current workflow stage of thetransaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; andpoll, by the second microservice, the streaming data platform toretrieve transactions matching the second workflow stage. The secondworkflow stage may be associated with the second microservice based onthe workflow corresponding to the transaction type. The instructions,when executed by the at least one processor, may further cause theplatform to retrieve, by the second microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the second workflow stage; process, by the secondmicroservice, the transaction object; update the current workflow stageof the transaction object to a third workflow stage based on completingprocessing, by the second microservice, of the transaction object;determine that the current workflow stage of the transaction objectindicates that the transaction object has completed processingcorresponding to the workflow; and remove the transaction object fromthe streaming data platform and output the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; updating the currentworkflow stage of the transaction object to a first workflow stage; andpolling, by a first microservice, the streaming data platform toretrieve transactions matching the first workflow stage. The firstworkflow stage may be associated with the first microservice based onthe workflow corresponding to the transaction type. The steps mayfurther comprise retrieving, by the first microservice and from thestreaming data platform, the transaction object based on the currentworkflow stage matching the first workflow stage; processing, by thefirst microservice, the transaction object; and polling, by a secondmicroservice, the streaming data platform to retrieve transactionsmatching the first workflow stage. The first workflow stage may be alsoassociated with the second microservice based on the workflowcorresponding to the transaction type. The steps may further compriseretrieving, by the second microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the first workflow stage; processing, by the secondmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice and the secondmicroservice, of the transaction object; and polling, by a thirdmicroservice, the streaming data platform to retrieve transactionsmatching the second workflow stage. The second workflow stage may beassociated with the third microservice based on the workflowcorresponding to the transaction type. The steps may further compriseretrieving, by the third microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching the second workflow stage; processing, by the thirdmicroservice, the transaction object; updating the current workflowstage of the transaction object to a third workflow stage based oncompleting processing, by the third microservice, of the transactionobject; determining that the current workflow stage of the transactionobject indicates that the transaction object has completed processingcorresponding to the workflow; and removing the transaction object fromthe streaming data platform and outputting the transaction object and anindication that the transaction object has completed the processingcorresponding to the workflow.

According to some aspects, a computer-implemented method may comprisesteps comprising receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; and retrieving, by a second microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the second workflow stage. The second workflow stage maybe associated with the second microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the second microservice, the transaction object; updatingthe current workflow stage of the transaction object to a third workflowstage based on completing processing, by the second microservice, of thetransaction object; determining that the current workflow stage of thetransaction object indicates that the transaction object has completedprocessing corresponding to the workflow; and removing the transactionobject from the streaming data platform and outputting the transactionobject and an indication that the transaction object has completed theprocessing corresponding to the workflow.

Configurator—Dynamic Microservice Configuration

One or more aspects described herein may provide for dynamicreconfiguration of the workflows and/or microservices. For example, aworkflow may be modified to change a progression of a transaction objectfrom one microservice to the next. This may be implemented by modifyingthe configuration of a microservice to look for a different currentworkflow stage on the streaming data platform. A microservice may bemodified to change processing logic and/or any other aspect controllinghow the microservice interacts with the streaming data platform and/ortransaction objects, or any other aspect of the microservice. Forexample, processing logic of the microservice may be changed to anupdated version to be used in processing future transactions.

A configuration interface may generate configuration transaction objectsthat cause the dynamic reconfiguration of the workflow and/ormicroservices. Configuration transaction objects may be added to the SDPwith a configuration workflow type, and the microservices may retrieveand process the configuration transaction objects. The configurationtransaction objects may operate such that a target micro service isreconfigured as a result of processing the configuration transactionobject, whether to look for transactions on a different workflow and/orworkflow stage, or to modify the processing logic applied to thetransactions retrieved by the microservice.

As discussed above, each defined workflow on transaction exchangeplatform 320 may accept a transaction as part of the transaction's“saga” through the transaction exchange platform. Through the workflow,the transaction may or may not undergo different processing steps, whereeach step may be provided by one or many microservices or vendorsystems. In this way, updating the “saga” that applies to themicroservices, integrated vendor systems and datasets, and the entiretransaction exchange ecosystem may be akin to an exercise inconfiguration control. Aspects described herein may allow configurationsto be loaded into the transaction exchange platform via the streamingdata platform, and may be used to update the entire transaction exchangeplatform, one or more components of the transaction exchange platform,and/or transactions on the platform.

Traditional methods for doing this may require that each element of theworkflow be updated, creating exponentially expanding complexity,downtime, and consequently interjecting risk to the transaction exchangeecosystem. Dynamic reconfiguration as described further herein may solvea problem of traditional deployments that interrupt the entire systemand require each component to be individually validated. It may alsointerject a level of control in the deployment by enabling any level ofcontrol from the level of remapping the system up to controlling whichcomponent gets transactions associated with different versions of thecorresponding workflow. Dynamic reconfiguration may also provide controlover the system so that configuration can work from the most tacticalsingle transaction (singleton) level up to the entire transactionexchange. Coupled with other tools, such as cloud-based resiliencytools, dynamic reconfiguration may provide a level of flexibility notpresent in other deployment approaches or solutions to simplifyingand/or mitigating the risk of a failed deployment.

The transaction exchange may exist in a space that includes numerouslegacy, vendor, and future state solutions. Dynamic reconfiguration mayprovide advantages in supporting partnering with vendors and thirdparties of any kind as an integration approach can be agreed on andbrought into the transaction exchange as a service controlled throughdynamic reconfiguration. Once integrated, similarly to the versioncontrol described herein, the integration service can be toggled on andoff easily through dynamic reconfiguration processes.

FIG. 6 illustrates a transaction processing system 600, similar to thatillustrated in FIG. 3A and sharing many like components. However,transaction processing system 600 includes configuration interface 660to provide dynamic reconfiguration of the workflows and/ormicroservices. Configuration interface 660 may push configurationtransaction objects to SDP 325 to cause re-configuration of a firstmicroservice 631 a (represented as first version 631 a, which may beupdated to second version 631 b). Due to dynamic reconfiguration,transaction objects may be modified to keep track of the workflowversion they should be processed under, as shown by example transactionobject 607.

Users managing transaction exchange platform 320 may determine todynamically reconfigure one or more aspects of the platform, such as bymodifying a workflow or causing a new version of a microservice to bedeployed. Reconfiguration may be prompted through other processes, suchas via a watchdog microservice as discussed further below with respectto FIG. 9 . Reconfiguration may be done to update and/or improvesoftware processes. Reconfiguration may also be done to address problemsthat arise during processing, such as when certain systems becomeunavailable or otherwise encounter problems. Reconfiguration may be doneas a new persistent configuration, or could be temporary pendingresolution of an issue. The reconfiguration may target any aspect of theplatform with desired granularity. For example, the reconfiguration mayapply to the entire platform, one or more microservices, and/or one ormore transactions, as appropriate. Workflows on transaction exchangeplatform 320 may also be reconfigured, which may be accomplished throughmodifying individual microservices to control the workflow type andworkflow stages that they watch for.

Configuration interface 660 may generate configuration transactionobjects that cause the dynamic reconfiguration of the workflow and/ormicroservices. Configuration transaction objects may be added to the SDPwith a configuration workflow type, and the microservices may retrieveand process the configuration transaction objects. Each microservice ontransaction exchange platform 320 may be configured to watch fortransaction objects having a configuration workflow type (e.g.,configuration transaction objects), and may have a correspondingworkflow stage similarly to that discussed above with respect to FIGS.3A and 4 .

A configuration transaction object may be configured such that, whenprocessed by a microservice, it causes reconfiguration of thatmicroservice. Microservices on the transaction exchange platform 320 maybe programmed to process configuration transaction objects and makesuitable changes to their parameters based on the processed objects. Forexample, a microservice may process configuration transaction objectcomprising instructions to update the workflow assigned to themicroservice to a second version of the workflow, e.g., ACH v. 2, andmay update a workflow stage assigned to the microservice.Reconfiguration of microservices can be used to update workflows to newversions, create new workflows, and/or modify existing workflows.Transactions requiring modified processing may be assigned tomodified/updated/other workflows to change their assigned processing.

Versioning may be used to control processing by appropriate workflows,and may facilitate reliable and accurate record keeping and playback. Bytracking which version of a workflow handles a transaction, thetransaction can be replayed using the same version at a later time aspart of an audit. To this end, microservices may maintain separateindications of each workflow and version handled by the microservice.Transactions may maintain transaction metadata indicating a versionvalue for the workflow applied to the transaction. Transactions may beassigned a current workflow value when added to the transaction exchangeplatform, and this may be maintained through the life of thetransaction. In some circumstances, the version may be changed later andthe transaction re-run through the new version of the workflow.

Examples of some types of changes that may be implemented throughdynamic reconfiguration will be discussed with references to FIGS.7A-7C.

FIG. 7A illustrates pushing a new configuration to one or more of themicroservices associated with example workflow 710, which may correspondto example wire transaction workflow 400. This new configuration maymodify the processing logic applied by one or more of the microservicescorresponding to the steps of workflow 400/710. Configuration interface660 may generate a configuration transaction object comprising the newconfiguration and push it to the SDP stream. The configurationtransaction object may cause update of the microservices mid-stream aspart of the flow within the transaction exchange platform on the SDP.Each microservice, as with transaction objects, may be configured towatch for configuration transaction objects associated with aconfiguration workflow and corresponding workflow stage. Themicroservices may retrieve matching configuration transaction objectsand process them to effect an update to their respective processinglogic. A microservice, transaction object, and/or the configurationmicroservice may maintain a new and prior version of theirconfigurations. This may allow for processing under an appropriateversion, and may facilitate a transition between versions as furtherdiscussed herein.

The mid-stream nature of the dynamic reconfiguration may help avoidsignificant interruptions and replayability problems posed by priorsolutions. As illustrated, transactions 20, 30, 31, 32, and 33 may be onthe SDP and already subject to processing by microservices in thecurrent version of the workflow. When a new configuration is pushed(such as version 6.0), the transactions pending on the SDP may continueto be processed according to the prior version that they started under(e.g., version 5.0). New transactions 34, 35, 36, and 37 may beprocessed under the new version (6.0). As described above, this may beeffected through transaction metadata tracking the workflow versionassociated with the transaction as well as by configuring themicroservices to utilize version metadata in retrieving transactionsfrom the SDP. For example, returning to FIG. 6 , microservice 631 a mayrepresent a first version of a microservice that looks for transactionsin a given workflow type that have a first version value at acorresponding first workflow stage. Microservice 631 b may represent asecond version of the microservice, and may look for transactions in thesame workflow type but having a second version value at the samecorresponding first workflow stage. In some implementations, the versionvalue may be combined with the workflow type rather than separate (e.g.,“ACHv1” and “ACHv2” as separate workflows rather than version values).

This procedure, pushing configuration transaction objects via the SDP,may provide additional advantages in that, when new components areadded, the configuration interface 660 can interject that new componentmid-stream so that it is enabled as a new route without updating theentire transaction exchange. This limits disruption to the local “new”component being added or changed while protecting the entire system forthe change. This may be advantageous as change remains one of the singlebiggest drivers of break events. It also enables on-the-fly updateswithout taking the entire system down into maintenance.

FIG. 7B illustrates a dynamic reconfiguration of a workflow process 720,such as when a component becomes unavailable due to breakage or otheradverse events. The dynamic reconfiguration may reconfigure the workflowto bypass problematic services and redirect the workflow to manualreview and/or other replacement processing steps. The reconfigurationmay avoid bottlenecks associated with microservices earlier in theworkflow breaking and preventing transactions from advancing to latermicroservices. Reconfiguration of workflows may be accomplished throughreconfiguring the microservices involved in the workflow to look fordifferent current workflow stages on the SDP.

For example, in reconfigured workflow process 720, which may be amodification of example wire transaction workflow 400, the dynamicreconfiguration may cause all wire transactions to be subject to theenhanced processing of step ‘C’ rather than the branching pathsdescribed above with respect to FIG. 4 . This may be due to enhancedsecurity concerns, problems with international wire processing, problemsat other components, etc. The reconfiguration of FIG. 7B may beaccomplished by configuration interface 660 pushing a configurationtransaction object to the SDP that is configured to cause themicroservices associated with workflow 400/720 to modify what workflowsand workflow stages they look for, as well as how they update thecurrent workflow once processing is completed. In particular, themodification shown in FIG. 7B could be effected by modifying themicroservice associated with step ‘D’ to not pull any transactions,while the microservice affiliated with step ‘C’ may pull alltransactions completed by step ‘B’; or step ‘B’ could be modified toupdate the current workflow of all processed transactions such that theyprogress to the enhanced verification of step ‘C’, for example.

Modifications to the workflow may be done in response to determiningconditions that indicate that modified workflow processing should beimplemented. The modifications may also be done in response to userchanges to a DAG representing the workflow. A user may modify the DAG todefine a new workflow/version and the configuration interface 660 maygenerate a suitable configuration transaction object and push it to theSDP to effect the change. The system may provide a graphical userinterface to facilitate users entering modifications to the DAGassociated with the workflow processing.

Reconfiguration of the workflows and/or microservices may be handled ina versioned manner, such that transactions on the SDP may be handledaccording to an appropriate and auditable version of the workflow. Whena new configuration version is pushed to the SDP for a given workflow,it may be added with a new version value. Transaction objects on thetransaction exchange platform may include, as part of their transactionmetadata, an indication of a current version value for the workflow atthe time they entered the transaction exchange platform. Themicroservices on the transaction exchange platform may be furtherconfigured to identify transaction objects having an appropriate currentworkflow stages based on the version value of the transaction object.Thus, transactions added under a first workflow version may reliably beprocessed under the first workflow version, while transaction addedafter a shift to a second workflow version may be processed using thenew, updated workflow version (and associated microservices andprocessing logic).

Thus, a first microservice in a first version 631 a may be originallyconfigured to watch for transactions associated with the first workflowthat have a first version value, while the first microservice in asecond version 631 b may be configured to watch for transactionsassociated with the first workflow that have a different second versionvalue. Transactions added to the transaction exchange platform may beadded having a first version value prior to reconfiguring the firstmicroservice. The first version of the first microservice 631 a mayretrieve transactions matching the first version value in acorresponding workflow/stage. Once a reconfiguration is pushed to theSDP, later transaction added to the SDP may be added having a secondversion value. The second version of the first microservice 631 b mayretrieve transaction matching the second version value in acorresponding workflow/stage. This may allow for reliable and replayableprocessing of transactions according to the appropriate version ofapproval workflows.

New workflow versions may be added as illustrated in FIG. 7C, throughworkflow 730. One flexible use of this approach is the ability togenerate a workflow designed to modify an individual transaction and/orgroup of transactions. Version 1 of the work flow, indicated by thesingle arrows, may be applied to general transaction objects of a giventransaction type. Version 2 of the workflow, indicated by the doublearrows, may be applied to problematic transactions subject to modifiedprocessing. The transaction exchange platform may support microservices,queuing, and manual workflows as part of being highly resilient,especially around high value workflows. As such, the dynamicconfiguration aspects may facilitate controlling a single transaction'spath through the platform enabling it to bypass steps normally requiredby the common workflow. A new workflow can be introduced to theecosystem with differentiating execution tied directly to a transaction.

As an example implementation, the following sample data illustrates howa workflow may change across versions of the workflow according to oneor more aspects:

Initial Configuration Version 1

{  “SecurityIdentifier”: “<< identifier >>”,  “ConfigurationVersion”:“1”,  “WorkflowStage”: [{   “A”: [{    “WorkflowType”: [“WIRE”, “ACH”,“RTP”, “CHECK”,    “CONFIG”],    “WorkflowStageCompleted”: [“INIT”]  }],   “B”: [{    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”,   “CONFIG”],    “WorkflowStageCompleted”: [“A”]   }],   “C”: [{   “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”,    “CONFIG”],   “WorkflowStageCompleted”: [“B”]   }],   “E”: [{    “WorkflowType”:[“WIRE”, “ACH”, “RTP”, “CHECK”,    “CONFIG”],   “WorkflowStageCompleted”: [“B”]   }],   “F”: [{    “WorkflowType”:[“WIRE”, “ACH”, “RTP”, “CHECK”,    “CONFIG”],   “WorkflowStageCompleted”: [“C”, “E”]   }],   “G”: [{   “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”,    “CONFIG”],   “WorkflowStageCompleted”: [“F”]   }]  }] }

Post Configuration Update Version 2

{  “SecurityIdentifier”: “<< identifier >>”,  “ConfigurationVersion”:“2”,  “WorkflowStage”: [{   “A”: [{     “WorkflowType”: [“WIRE”, “ACH”,“RTP”, “CHECK”,     “CONFIG”],    “WorkflowStageCompleted”: [“INIT”]  “B”: [{    “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”,   “CONFIG”],    “WorkflowStageCompleted”: [“A”]   }],   “D”: [{   “WorkflowType”: [“WIRE”, “ACH”, “RTP”, “CHECK”,    “CONFIG”],   “WorkflowStageCompleted”: [“B”]   }],   “C”: [{    “WorkflowType”:[“WIRE”, “ACH”, “RTP”, “CHECK”,    “CONFIG”],   “WorkflowStageCompleted”: [“D”]   }],   “F”: [{    “WorkflowType”:[“WIRE”, “ACH”, “RTP”, “CHECK”,    “CONFIG”],   “WorkflowStageCompleted”: [“C”]   }];   “G”: [{   “WorkflowType”:[“WIRE”, “ACH”, “RTP”, “CHECK”,   “CONFIG”],   “WorkflowStageCompleted”:[“F”]   }]  }] }

Another aspect of dynamic reconfiguration may provide an eventconfiguration library. Configurations employed to process transactionshave certain characteristics may be stored for re-use in other settings,such as when those same characteristics are encountered again.Configurations that were pushed to resolve those transaction may be usedagain to facilitate handling of other similar transactions. For example,if manual or other review identifies a high risk transaction, a highrisk transaction configuration can be pushed to apply a high riskversion of the workflow to the high risk transaction. As a particularexample, consider when a transaction is associated with a merger of twocompanies. To facilitate the merger, transactions may be reconfigured tobypass standard workflows and feed through specialized microservicesconfigured to meet specific reporting needs of M&A transactions.

These configurations may be utilized manually, automatically, through ahybrid approach, and others. For example, machine learning may beemployed to recognize problem situations with transactions. The machinelearning system may flag a transaction to be reconfigured to follow aconfiguration of the configuration library that was previously employedon similar transactions. The system may be designed to self-optimize itsown configurations, employing approaches based on features such asshortest path, fastest time, most secure, guaranteed deliver, or anyother features desirable to customers.

FIG. 8 depicts a flowchart illustrating an example method 800 todynamically reconfigure a transaction exchange platform, such astransaction exchange platform 320. Method 800 may be performed by anysuitable computing device and/or combination of computing devices,referred to as the system implementing method 800.

At step 805, the configuration interface 660 may generate aconfiguration transaction object. The configuration transaction objectmay be configured to cause a reconfiguration of the transaction exchangeplatform, one or more workflows, one or more microservices, and/or oneor more transactions. The configuration interface 660 may receive arequest to generate the configuration transaction object from a userand/or other system processes, such as a watchdog microservice(discussed further below with respect to FIG. 9 ). The configurationtransaction object may comprise transaction details and transactionmetadata. The transaction metadata may indicate that the transactionobject has a configuration workflow type and a current workflow stage ofthe configuration transaction object. In some embodiments, the workflowtype of the configuration transaction object is a workflow that ismodified by the configuration transaction object, and other aspects ofthe configuration transaction object indicate to a processingmicroservice that it includes an update to the processing of themicroservice. The configuration transaction object may includeinstructions that, when processed by the microservice, cause themicroservice to be reconfigured. Reconfiguration may include modifyingwhich workflow/version/stage the microservice looks for on the SDP,and/or may include modifying the core processing logic employed by themicroservice.

At step 810, the configuration interface 660 may add the configurationtransaction object to the SDP, where it may await processing by firstmicroservice 820 and second microservice 830.

The configuration transaction object may be picked up by firstmicroservice 820 and second microservice 830 in a similar fashion tothat described above with respect to FIG. 5 . At steps 821 and 831,first and second microservices 820 and 830 may poll the SDP to retrievetransactions matching their assigned workflow stages in correspondingworkflow types. The configuration transaction objects may have aconfiguration workflow type, and the microservices may watch for aconfiguration workflow type object having the workflow stagecorresponding to the microservice. At steps 823 and 833, themicroservices may retrieve the configuration transaction object forprocessing.

At steps 825 and 835, the microservices may process the configurationtransaction object when it is in a corresponding workflow stage.Processing the configuration transaction object may cause themicroservice to be updated. For example, the configuration transactionobject may cause the microservice to update what workflow/version/stageit looks for on the SDP. As another example, processing theconfiguration transaction object may cause the microservice to updatethe core processing logic that it applies to transactions.

At steps 827 and 837, the microservices may update the current workflowstage of the configuration transaction object and, at steps 829 and 839,the microservices may push the updated configuration object back to theSDP. For example, microservice 820 may update the current workflow stageof the configuration object to indicate that microservice 820 hascompleted processing, and microservice 830 may be configured to look fortransaction objects that have a current workflow stage that indicatesthat microservice 820 completed its processing.

At step 840, the system may determine that the current workflow stage ofthe configuration transaction object indicates that the processingassociated with the configuration workflow has completed, and theconfiguration transaction object may be removed from the SDP.Notification may be provided to an entity that prompted thereconfiguration that it has been implemented, in some embodiments.

Thus, according to some aspects, a computer-implemented method maycomprise configuring a plurality of microservices on a streaming dataplatform to watch for transactions having a corresponding workflow stageassociated with a first workflow. The first workflow may correspond to atransaction type and may comprise a plurality of processing stepsrequired to approve a given transaction of the transaction type. Thesteps may further comprise generating a configuration transaction objectthat may be configured to cause reconfiguration of the first workflow bycausing reconfiguration of at least one microservice of the plurality ofmicroservices. The configuration transaction object may comprisetransaction metadata that indicates a configuration workflow and acurrent workflow stage of the configuration transaction object. Thesteps may further comprise adding the configuration transaction objectto the streaming data platform and updating the current workflow stageof the configuration transaction object to a first workflow stage. Themethod may comprise polling, by a first microservice of the plurality ofmicroservices, the streaming data platform to retrieve transactionsmatching the first workflow stage; retrieving, by the first microserviceand from the streaming data platform, the configuration transactionobject based on the current workflow stage matching the first workflowstage; processing, by the first microservice, the configurationtransaction object to reconfigure the first microservice; and updatingthe current workflow stage of the configuration transaction object to asecond workflow stage based on completing processing, by the firstmicroservice, of the configuration transaction object. The method mayalso comprise determining that the current workflow stage of theconfiguration transaction object indicates that the configurationtransaction object has completed processing corresponding to theconfiguration workflow, and removing the configuration transactionobject from the streaming data platform and outputting an indicationthat the configuration transaction object has completed the processingcorresponding to the configuration workflow.

Reconfiguring the first microservice may comprise reconfiguring thefirst microservice to watch for a different second workflow stage.Reconfiguring the first microservice may cause the first microservice toprocess transaction objects at a different stage of the plurality ofprocessing steps of the first workflow. Reconfiguring the firstmicroservice may comprise reconfiguring the first microservice to modifyat least one operation that the first microservice performs ontransaction objects associated with the first workflow. Reconfiguringthe first microservice may cause removal of at least one secondmicroservice from the first workflow. The first microservice may beoriginally configured to update completed transactions with a firstcompleted workflow stage. Reconfiguring the first microservice maycomprise reconfiguring the first microservice to update completedtransactions with a different completed workflow stage. Reconfiguringthe first microservice may cause transaction objects to bypass at leastone second microservice included in the first workflow. The firstmicroservice may be originally configured to watch for transactionsassociated with the first workflow that have a first version value. Thereconfigured first microservice may be configured to watch fortransactions associated with the first workflow that have a differentsecond version value.

The method may further comprise adding a first transaction object havinga first version value to the streaming data platform prior toreconfiguring the first microservice; retrieving, by the firstmicroservice and from the streaming data platform, the first transactionobject based on a current workflow stage of the first transactionmatching the first workflow stage; processing, by the firstmicroservice, the first transaction object based on an originalconfiguration of the first microservice based on the first versionvalue; adding a second transaction object having a different secondversion value to the streaming data platform subsequent to reconfiguringthe first microservice; retrieving, by the first microservice and fromthe streaming data platform, the second transaction object based on acurrent workflow stage of the second transaction matching the firstworkflow stage; and processing, by the first microservice, the secondtransaction object based on the reconfiguration of the firstmicroservice based on the second version value. The steps may furthercomprise adding a first transaction object to the streaming dataplatform; determining a current version of the first workflowimplemented on the streaming data platform; and updating a version valueof the first transaction object based on the current version. The firstmicroservice may process the first transaction object based on anoriginal configuration or a modified configuration based on the versionvalue.

The workflow corresponding to the transaction type may comprise adirected acyclic graph (DAG) indicating the plurality of processingsteps required to approve a given transaction of the transaction type.The first microservice may be automatically configured to watch fortransactions on the streaming data platform in the first workflow stagebased on the DAG. Generating the configuration transaction object may bein response to an update to at least one of the plurality of processingsteps indicated in the DAG. The steps may further comprise providing agraphical user interface to allow a user to update the at least one ofthe plurality of processing steps indicated in the DAG.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be automatically configured to watch for transactionson the streaming data platform in a corresponding workflow stage basedon a plurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingconfiguring the plurality of microservices on the streaming dataplatform to watch for transactions having a corresponding workflow stageassociated with a first workflow. The first workflow may correspond to atransaction type and comprises a plurality of processing steps requiredto approve a given transaction of the transaction type. The steps mayfurther comprise processing, by a first microservice, transactionobjects on the streaming data platform based on the configuration; andgenerating a configuration transaction object that may be configured tocause reconfiguration of the first workflow by causing reconfigurationof at least one of microservice of the plurality of microservices. Theconfiguration transaction object may comprise transaction metadata thatindicates a configuration workflow and a current workflow stage of theconfiguration transaction object. The steps may further comprise addingthe configuration transaction object to the streaming data platform;updating the current workflow stage of the configuration transactionobject to a first workflow stage; polling, by a first microservice ofthe plurality of microservices, the streaming data platform to retrievetransactions matching the first workflow stage; retrieving, by the firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching thefirst workflow stage; and processing, by the first microservice, theconfiguration transaction object to reconfigure the first microservice.Subsequent to processing the configuration transaction object, the firstmicroservice may process transaction objects on the streaming dataplatform based on the reconfiguration.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise configuring a first microservice on a streaming dataplatform to watch for transactions having a first workflow stageassociated with a first workflow corresponding to a transaction type.The first workflow may comprise a plurality of processing steps requiredto approve a given transaction of the transaction type. The steps mayfurther comprise configuring a second microservice on the streaming dataplatform to watch for transactions having a second workflow stageassociated with the first workflow; and generating a configurationtransaction object that may be configured to cause reconfiguration ofthe first workflow by causing reconfiguration of the first microserviceand the second microservice. The configuration transaction object maycomprise transaction metadata that indicates a configuration workflow,and a current workflow stage of the configuration transaction object.The steps may further comprise adding the configuration transactionobject to the streaming data platform; updating the current workflowstage of the configuration transaction object to the first workflowstage; polling, by the first microservice, the streaming data platformto retrieve transactions matching the first workflow stage; retrieving,by the first microservice and from the streaming data platform, theconfiguration transaction object based on the current workflow stagematching the first workflow stage; processing, by the firstmicroservice, the configuration transaction object to reconfigure thefirst microservice; updating the current workflow stage of theconfiguration transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the configurationtransaction object; polling, by the second microservice, the streamingdata platform to retrieve transactions matching the second workflowstage; retrieving, by the second microservice and from the streamingdata platform, the configuration transaction object based on the currentworkflow stage matching the second workflow stage; processing, by thesecond microservice, the configuration transaction object to reconfigurethe second microservice; updating the current workflow stage of theconfiguration transaction object to a third workflow stage based oncompleting processing, by the second microservice, of the transactionobject; determining that the current workflow stage of the configurationtransaction object indicates that the configuration transaction objecthas completed processing corresponding to the configuration workflow;and removing the configuration transaction object from the streamingdata platform and outputting an indication that the configurationtransaction object has completed the processing corresponding to theconfiguration workflow.

According to some aspects, a computer-implemented method may comprisesteps comprising configuring a plurality of microservices on a streamingdata platform to watch for transactions having a corresponding workflowstage associated with a first workflow. The first workflow maycorrespond to a transaction type and comprises a plurality of processingsteps required to approve a given transaction of the transaction type.The steps may further comprise generating a configuration transactionobject that may be configured to cause reconfiguration of the firstworkflow by causing reconfiguration of at least one microservice of theplurality of microservices. The configuration transaction object maycomprise transaction metadata that indicates: a configuration workflow,and a current workflow stage of the configuration transaction object.The steps may further comprise adding the configuration transactionobject to the streaming data platform; retrieving, by a firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching a firstworkflow stage associated with the first microservice; processing, bythe first microservice, the configuration transaction object toreconfigure the first microservice; and updating the current workflowstage of the configuration transaction object to a second workflow stagebased on completing processing, by the first microservice, of theconfiguration transaction object.

Chronos—Snapshot Microservice and Transaction Replay

Some aspects described herein may provide a snapshot microservice on thetransaction exchange platform, configured to maintain a record of thedata values of each transaction object as they progress through thecorresponding workflows. “Snapshot,” when used to refer to the snapshotmicroservice, may refer to the functionality of the snapshotmicroservice to track a transaction object's data values and each of itschanged states as an archival service. The snapshot microservice thusmay also be referred to as a payment transaction object changed statearchive, or Chronos. The snapshot microservice may create a snapshotrecord for new transaction objects and store a copy of the data of thetransaction object. As the transaction object progresses through theworkflow and is processed by the other microservices, the snapshotmicroservice can identify transaction objects that have their datachanged. The snapshot microservice can retrieve the changed objects andstore snapshot data tracking the change of the transaction object.

FIG. 9 illustrates a transaction processing system 900 that may besimilar to transaction processing systems 300 and/or 600 of FIGS. 3A and6 . Transaction processing system 900 may add, relative to systems 300and 600, snapshot microservice 970 and watchdog microservice 980. Thisdocument section focuses on snapshot microservice 970, while the nextdocument section focuses on watchdog microservice 980.

Snapshot microservice 970 may operate on transaction exchange platform320 to maintain a record of the data values of each transaction objecton the streaming data platform, and may track how the transactionobjects change during processing on the platform. Snapshot data may bestored in snapshot database 975, which may comprise on-disk storagecapable of effectively storing large volumes of data. Snapshotmicroservice 970 and snapshot database 975 may be configured to storedifferential snapshots of a transaction object. Snapshot microservice970 may store an original state of a transaction object when it is addedto the SDP, and may store information indicating each subsequent changeto the transaction object. Snapshot microservice may track data valuesassociated with each of the transaction details, transaction addendadata, and/or transaction metadata. In some embodiments however, thetransaction metadata may be additionally and/or alternatively tracked bywatchdog microservice 980.

The snapshot microservice 970 may be configured to identify and retrievetransaction objects added to SDP 325 in an initialization stage.Transaction objects may be added to the SDP 325 in an “init” orinitialization stage, indicating that none of the workflow steps haveyet been completed. In some implementations, the initialization stagemay be a separate stage that is marked completed prior to processing bya first microservice 331, or may be commensurate in scope with a firstworkflow stage associated with a first microservice 331 of the workflow.In some implementations, the initialization stage for the object may behandled as part of the processing by the APIs 311, 313 that receivetransactions to be added to the SDP 325, or otherwise handled alongsideworkflow processing by the respective microservices 331, 332, and 333.

Snapshot microservice 970 may store an initial snapshot of a transactionobject in the initialization stage, then update a current workflow stageof the transaction object to indicate that the initialization processinghas completed. This may comprise updating the current workflow stage ofthe transaction object to match a first workflow stage associated withmicroservice 331, which microservice 331 performs the first step of theworkflow. Alternatively, snapshot microservice 970 may treat transactionobjects in the first workflow stage as being subject to initialization(as new objects), and may determine that an initial, new snapshot shouldbe recorded in snapshot database 975.

Snapshot microservice 970 may be configured to poll the SDP to retrieveall transaction objects having changed data. In some embodiments, thismay comprise retrieving all transaction objects and determining whetherthere have been any changes. In other embodiments, it may compriseretrieving specifically the transaction objects that have changed,whether based on determining that the data has changed or merely that aworkflow stage has advanced. Snapshot microservice 970 may determine adifference in the changed transaction object and store snapshotinformation indicating the difference. The snapshot information mayinclude metadata such as an associated timestamp, workflow stage, and/orany other suitable metadata to facilitate audit and potential rollbackof the transaction object and workflow processing.

These snapshots of the transaction object may be used to correctprocessing errors in the approval workflow, as a transaction object mayhave its data reverted back to an earlier state and its workflow stagereverted to an earlier stage. In this way, the transaction object may bemade to repeat an earlier step of the workflow and be subject tore-processing by a corresponding microservice (or, in some cases such asrepeated failures, a human operator). The snapshot microservice 970 mayregenerate a transaction object using the snapshot data corresponding tothe transaction object from an earlier time, prior to a point inprocessing that is subject to the rewind. In effect, snapshotmicroservice 970 may roll back the values of the transaction object toan earlier point in time. Then, the regenerated transaction object maybe put back on SDP 325 and will be picked up for re-processing by theearlier microservice. For example, if an error is determined to haveoccurred during processing of transaction object 307 by firstmicroservice 331, the snapshot microservice 970 may revert transactionobject 307 to state prior to processing by first microservice 331. Thefirst microservice 331 would have updated the stage of the transactionobject 307 to the second workflow stage when processing completed. Thesnapshot microservice 970 may revert the current workflow stage of thetransaction object 307 to the first workflow stage, so that when thetransaction object 307 is pushed back to the SDP 325 it will be pickedup for processing again by the first microservice 331.

A command to replay a transaction may be received by the snapshotmicroservice 970. For example, watchdog microservice 980 may determinethat processing by first microservice 331 completed abnormally, and maycommand snapshot microservice 970 to perform a replay. Other conditionsmay prompt a replay, such as an error state of a microservice or thetransaction exchange platform 320.

The snapshot microservice may track the total number of times that atransaction object is reverted/replayed on one or more microservices,and may flag a transaction as presenting problems requiring manual orother review when the number of replays exceeds a transaction or basedon other criteria. Replaying a transaction may cause update of atransaction replay count associated with the transaction, which may bestored as part of the transaction object's transaction metadata and/oras part of the snapshot information. If a threshold number of replaystake place, for example a configurable maximum of 3 replays at a singlestage of the workflow, the snapshot microservice 970 may flag thetransaction as having failed and/or requiring further review. Themaximum, which may be implemented as a threshold value, may beconfigured by a user and/or may be automatically configured by systemprocesses based on historical data, current system state, and otherperformance metrics. The transaction may be held in a workflow stagecorresponding to the microservice where processing failed, in someinstance. In other instances, a failed transaction may be routed toadditional processing, such as by a different workflow and/or otherparts of the same workflow, where it may be processed by othermicroservices.

When a replay occurs, the snapshot information may continue to track allsubsequent events as well as all events that had occurred already on thetransaction, even if they are subject to rewinding. Thus, the snapshotinformation may support a comparison during troubleshooting to assesswhich parts of the system led to errors in the workflow. Thisinformation may be archived to assist in troubleshooting and audits.Snapshot information related to error processing that is fixed viareplay may be deleted upon successful completion of the re-attempt.

The snapshot data may also support audit of the transactions, offering acomplete picture of how the transaction object changed while on thetransaction exchange platform. If desired as part of auditing results,the snapshot microservice 970 may replay an entire transaction snapshotby snapshot. This may be done in support of an audit or fortroubleshooting and analysis.

FIG. 10 depicts a flowchart illustrating an example method 1000 togenerate snapshot information tracking a transaction object on atransaction exchange platform, such as transaction exchange platform320. Method 1000 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1000.

At step 1005, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1031, snapshot microservice 1030 may store an initial snapshotrecord for new transaction objects on the SDP. For example, snapshotmicroservice 1030 may poll the SDP for transaction objects in theinitialization stage. Alternatively and/or additionally, snapshotmicroservice 1030 may poll SDP for all transaction objects, anddetermine which are new and should be stored as initial snapshotrecords.

At step 1033, snapshot microservice 1030 may update the current workflowstage of the transaction object to indicate completion of initializationprocessing by the snapshot microservice 1030. This may comprise updatingthe current workflow stage of the transaction object to be a workflowstage associated with a workflow microservice 1020. At step 1035,snapshot microservice 1030 may put the transaction object back to theSDP with the updated current workflow stage.

At step 1021, workflow microservice 1020 may poll the SDP fortransactions having a current workflow stage assigned to themicroservice, and at step 1023 the workflow microservice may retrievethe matching transaction objects. At step 1025, workflow microservice1020 may process the transaction objects according to its respectiveprocessing logic, which may include updating, adding, removing, and/orotherwise changing values of the transaction details, addenda data,and/or transaction metadata associated with the transaction object. Atstep 1027, workflow microservice 1020 may update the transactionobject's current workflow stage to indicate completion of processing bymicroservice 1020 and, at step 1029, put the updated transaction objectback to the SDP.

At step 1037, snapshot microservice 1030 may poll the SDP fortransactions and, at step 1039, determine transaction having changeddata. Snapshot microservice 1030, at step 1041, may record snapshot datacorresponding to the changed data as a result of processing by workflowmicroservices 1020. The snapshot microservice 1030 may, at step 1043,put the transaction object back to the SDP for further processing byworkflow microservices 1020.

FIG. 11 depicts a flowchart illustrating an example method 1100 toreplay a transaction (e.g., subject it to reprocessing) using a snapshotmicroservice on a transaction exchange platform, such as transactionexchange platform 320. Method 1100 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 1100.

At step 1105, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

The transaction object may be processed by microservice 1120 in steps1121, 1123, 1125, 1127, and 1129 as described herein, for example insimilar fashion to that described with respect to FIG. 10 in steps 1021,1023, 1025, 1027, and 1029.

Snapshot microservice 1130 may record initial and changed snapshotinformation in steps 1131 and 1131, as described in greater detail abovewith respect to FIG. 10 in steps 1031, 1033, 1035, 1037, 1039, 1041, and1043.

At step 1135, snapshot microservice 1130 may receive a command to replaya workflow step for a transaction object. For example, a watchdogmicroservice may send snapshot microservice 1130 a command to replay thetransaction object in a first workflow stage.

At step 1137, snapshot microservice 1130 may use the stored snapshotinformation to rollback the transaction object to its state prior to thepoint of replay. The transaction object may be made to repeat an earlierstep of the workflow and be subject to re-processing by a microserviceto the workflow step indicated to be replayed. The snapshot microservice1130 may regenerate a transaction object using the snapshot datacorresponding to the transaction object from an earlier time, prior to apoint in processing that is subject to the rewind.

At step 1139, snapshot microservice 1130 may put the regeneratedtransaction object back on the SDP. Because the regenerated transactionobject has the earlier workflow stage, it will be picked up forre-processing by the earlier microservice.

Thus, according to some aspects, a computer-implemented method maycomprise steps comprising receiving a transaction object comprisingtransaction details, addenda data, and transaction metadata. Thetransaction metadata may comprise an indication of a workflowcorresponding to a transaction type of the transaction object, and acurrent workflow stage of the transaction object. The workflowcorresponding to the transaction type may comprise a plurality ofprocessing steps required to approve a given transaction of thetransaction type. The steps may further comprise adding the transactionobject to a streaming data platform. Adding the transaction object tothe streaming data platform may comprise setting the current workflowstage of the transaction object to an initialization stage. The stepsmay further comprise polling, by a snapshot microservice, the streamingdata platform to retrieve transactions matching the initializationstage. The initialization stage may be associated with the snapshotmicroservice. The steps may further comprise retrieving, by the snapshotmicroservice and from the streaming data platform, the transactionobject based on the current workflow stage matching the initializationstage; storing, by the snapshot microservice, snapshot datacorresponding to the transaction object; and updating the currentworkflow stage of the transaction object to a next workflow stage basedon completing storing, by the snapshot microservice, the snapshot datacorresponding to the transaction object. The method may compriseretrieving, by a first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching a first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the first microservice, the transaction object to modifythe addenda data. The method may comprise determining, by the snapshotmicroservice and via the streaming data platform, that at least onevalue associated with the addenda data of the transaction object haschanged after the transaction object has left the initialization stage,and storing, by the snapshot microservice, snapshot data correspondingto the changed at least one value associated with the addenda data.

Determining that the at least one value associated with the addenda dataof the transaction object has changed may comprise retrieving, by thesnapshot microservice and from the streaming data platform, thetransaction object. The steps may further comprise determining that theprocessing, by the first microservice, of the transaction object did notcomplete successfully, and causing the first microservice to repeatprocessing of the transaction object based on the snapshot datacorresponding to the transaction object from prior to the start of theprocessing by the first microservice. Causing the first microservice torepeat processing of the transaction object may comprise regenerating,by the snapshot microservice, the transaction object based on thesnapshot data corresponding to the transaction object from prior to thestart of the processing by the first microservice, and returning theregenerated transaction object to the streaming data platform. Thecurrent workflow stage of the regenerated transaction object may be setto the first workflow stage. The steps may further comprise determininga number of times that the transaction object has undergone processingby the first microservice and, in response to determining that thenumber of times that the transaction object has undergone processing bythe first microservice exceeds a threshold value, rejecting thetransaction object as having failed processing associated with the firstmicroservice. The steps may further comprise flagging the transactionobject for further review based on rejecting the transaction and holdingthe transaction object in the first workflow stage pending the furtherreview. Updating the current workflow stage of the transaction object toa second workflow stage may be based on determining that the furtherreview is completed. Flagging the transaction object for further reviewmay comprise flagging the transaction object for manual review by auser. Flagging the transaction object for further review may comprisecausing the transaction object to be processed by a third microservice.Updating the current workflow stage of the transaction object to thesecond workflow stage may be based on determining that processing by thethird microservice is completed. The snapshot microservice may recordsecond snapshot data corresponding to the transaction object from priorto causing the first microservice to repeat processing of thetransaction object. The second snapshot data may be maintained despitethe repeat processing of the transaction object.

The steps may further comprise determining, by the snapshot microserviceand via the streaming data platform, that at least one value associatedwith the transaction metadata has changed; retrieving, by the snapshotmicroservice and from the streaming data platform, the transactionobject based on determining that the at least one value has changed; andstoring, by the snapshot microservice, data corresponding to the changedat least one value associated with the transaction metadata. The nextworkflow stage may correspond to the first workflow stage associatedwith the first microservice. The initialization stage may correspond tothe first workflow stage. The snapshot microservice may generate atransaction history for the transaction object. The snapshotmicroservice may generate a transaction history for each transactionobject added to the streaming data platform. The snapshot microservicemay store snapshot data in an on-disk database.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each micro service of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details, addendadata, and transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform. Adding the transactionobject to the streaming data platform may comprise setting the currentworkflow stage of the transaction object to an initialization stage. Thesteps may further comprise polling, by a snapshot microservice, thestreaming data platform to retrieve transactions matching theinitialization stage. The initialization stage may be associated withthe snapshot microservice. The steps may further comprise retrieving, bythe snapshot microservice and from the streaming data platform, thetransaction object based on the current workflow stage matching theinitialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the transaction object, updating thecurrent workflow stage of the transaction object to a next workflowstage based on completing storing, by the snapshot microservice, thesnapshot data corresponding to the transaction object; and retrieving,by a first microservice and from the streaming data platform, thetransaction object based on the current workflow stage matching a firstworkflow stage. The first workflow stage may be associated with thefirst microservice based on the workflow corresponding to thetransaction type. The steps may further comprise processing, by thefirst microservice, the transaction object to modify the addenda data;determining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with the addenda data ofthe transaction object has changed after the transaction object has leftthe initialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data.

The steps may further comprise determining that the processing, by thefirst microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice. Causing the first microservice to repeat processingof the transaction object may comprise causing the transaction exchangeplatform to regenerate, by the snapshot microservice, the transactionobject based on the snapshot data corresponding to the transactionobject from prior to the start of the processing by the firstmicroservice; and return the regenerated transaction object to thestreaming data platform. A current workflow stage of the regeneratedtransaction object may be set to the first workflow stage. The snapshotmicroservice may generate a transaction history for each transactionobject added to the streaming data platform.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails, addenda data, and transaction metadata. The transactionmetadata may comprise an indication of a workflow corresponding to atransaction type of the transaction object, and a current workflow stageof the transaction object. The workflow corresponding to the transactiontype may comprise a plurality of processing steps required to approve agiven transaction of the transaction type. The steps may furthercomprise adding the transaction object to a streaming data platform.Adding the transaction object to the streaming data platform maycomprise setting the current workflow stage of the transaction object toan initialization stage. The steps may further comprise polling, by asnapshot microservice, the streaming data platform to retrievetransactions matching the initialization stage. The initialization stagemay be associated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; and storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object,updating the current workflow stage of the transaction object to a nextworkflow stage based on completing storing, by the snapshotmicroservice, the snapshot data corresponding to the transaction object;and retrieving, by a first microservice and from the streaming dataplatform, the transaction object based on the current workflow stagematching a first workflow stage. The first workflow stage may beassociated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further compriseprocessing, by the first microservice, the transaction object to modifythe addenda data; determining, by the snapshot microservice and via thestreaming data platform, that at least one value associated with theaddenda data of the transaction object has changed after the transactionobject has left the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the changed at least onevalue associated with the addenda data; determining that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice. Causing the first microservice to repeat processingof the transaction object may comprise regenerating, by the snapshotmicroservice, the transaction object based on the snapshot datacorresponding to the transaction object from prior to the start of theprocessing by the first microservice; and returning the regeneratedtransaction object to the streaming data platform. A current workflowstage of the regenerated transaction object may be set to the firstworkflow stage.

Arbiter—Watchdog Microservice for Tracking, Monitoring, and Remediation

Some aspects described herein may provide a watchdog microservice on thetransaction exchange platform, configured to track the progress oftransaction objects through their respective workflows. “Watchdog,” whenreferring to the watchdog microservice, may refer to the functionalityof the watchdog microservice to observe and archive the progress oftransaction objects on the transaction exchange platform, and enforcethe associated workflows. Thus the watchdog microservice may also bereferred to as an observability and archive microservice, or Arbiter.The watchdog microservice may determine that a transaction object hascompleted the approval workflow based on the transaction objectcompleting each component step of the workflow, and may cause thecompleted transaction to be output from the transaction exchangeplatform. The watchdog microservice may also enforce the workflow,causing transactions to repeat and/or revisit problematic steps of theworkflow.

The watchdog microservice may track metrics and/or other statisticsassociated with the workflows, microservices, and/or transactions. Basedon the tracked workflow data, the watchdog microservice may be able toassess trends associated with a workflow, microservice, or transaction.The watchdog microservice may compare a metric and/or other statistic tothreshold performance values to determine when the workflow,microservice, or transaction is subject to abnormal or undesirableperformance complications. For example, the watchdog microservice coulddetermine that a particular microservice has a current averageprocessing time greater than a configured warning threshold, or outsidea typical range. Based on detecting abnormal or undesirable performanceof the workflow, microservice, or transaction, the watchdog microservicecan generate and/or implement a recommended corrective action. Examplecorrective actions may include causing a transaction to be replayed viaa snapshot microservice, and causing a workflow to be dynamicallyreconfigured using a configuration interface.

FIG. 9 , discussed above with respect to the snapshot microservice, alsodepicts watchdog microservice 980 and watchdog database 985. Watchdogmicroservice 980 may generate workflow tracking records for eachtransaction object on the transaction exchange platform 320, and maystore information indicating whether the transaction object completedeach step of the workflow along with timestamps and other suitablemetadata. The workflow tracking records may be stored in watchdogdatabase 985, which may comprise an in-memory database configured tosupport quick access and retrieval of records while on SDP 325.

The watchdog microservice 980 may serve as the judge (arbiter) indetermining when a transaction object has completed the workflowprocessing steps of its corresponding workflow. This is furtherdescribed with respect to FIG. 12 .

FIG. 12 depicts a flowchart illustrating an example method 1200 to trackworkflow progress and determine if a transaction has completed theworkflow on a transaction exchange platform, such as transactionexchange platform 320. Method 1200 may be performed by any suitablecomputing device and/or combination of computing devices, referred to asthe system implementing method 1200.

At step 1205, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1231, watchdog microservice 1230 may store an initial record fornew transaction objects on the SDP. Watchdog microservice 1230 mayidentify new transactions on the SDP, potentially as a result of theinitialization stage, and may generate new workflow tracking records forthe new transaction objects. Watchdog microservice 1230 may poll the SDPto retrieve new transactions as they are added. Additionally and/oralternatively, watchdog microservice 1230 may poll the SDP to retrieveall new transactions and determine which are new, as shown in step 1233.

Workflow microservices 1220 may process transaction objects on the SDPin the manners described above in detail. For example, illustrated steps1221, 1223, 1225, 1227, and 1229 may correspond to steps 1021, 1023,1025, 1027, and 1029 of FIG. 10 .

At step 1233, watchdog microservice 1230 may poll the SDP fortransactions and, at step 1235, determine transaction objects having achanged workflow stage. In some embodiments, watchdog microservice 1230may poll all transactions and determine which have changes. In otherembodiments, watchdog microservice 1230 may poll the SDP to requesttransaction that have changed.

At step 1237, watchdog microservice 1230 may record workflow trackingdata corresponding to the change in the workflow stage of thetransaction object. For example, watchdog microservice 1230 may update aworkflow tracking record associated with the transaction object toindicate it completed a workflow stage associated with a workflowmicroservice 1220. The watchdog microservice 1230 may further storeother metadata regarding the updated workflow stage, including atimestamp of the recorded change.

At step 1239, the watchdog microservice 1230 may determine whether thecurrent workflow stage of the transaction object (and/or the workflowtracking data) indicate that the transaction object has met therequisite steps of the workflow associated with the transaction type ofthe transaction objects. For example, the watchdog microservice 1230 mayassess whether the current workflow stage information of the transactionmetadata indicates completion of a series of steps that satisfy thecriteria of the workflow associated with a particular transaction typeof the transaction object.

At step 1241, the watchdog microservice 1230 may determine that theworkflow is not complete, and may proceed to step 1245 where thetransaction object is put back to the SDP after recording the workflowtracking information.

If, at step 1241, the watchdog microservice 1230 determines that theworkflow is complete, processing may proceed to step 1243 where thetransaction object is removed from the SDP of the transaction exchangeplatform and output as completed. For example, the transaction objectmay be updated with an indication that it completed the workflow and isapproved, and may be put to a public SDP 340 accessible to enterprisesystems and users 350.

Additionally and/or alternatively to the workflow completiondeterminations described above, the watchdog microservice 980/1230 mayenforce the individual steps of the workflow. The watchdog microservicemay assess whether a current workflow stage indicates a valid workflowstage under the restrictions of the workflow structure. If the currentworkflow stage of the transaction object is not valid, the watchdogmicroservice may cause the transaction object to be processed by one ormore appropriate microservices associated with the workflow, therebyenforcing the workflow. Working in conjunction with the snapshotmicroservice, the watchdog microservice may cause a transaction torepeat a step of the workflow by reverting the transaction object to anearlier state in response to detecting problems.

According to some aspects, the watchdog microservice may track metricsand/or other statistics associated with the workflows, microservices,and/or transactions. Based on the tracked workflow data, the watchdogmicroservice may be able to assess trends associated with a workflow,microservice, or transaction. The watchdog microservice may compare ametric and/or other statistic to threshold performance values todetermine when the workflow, microservice, or transaction is subject toabnormal or undesirable performance complications. This is describedfurther below with respect to FIG. 13 .

FIG. 13 depicts a flowchart illustrating an example method 1300 to trackworkflow progress and recommend corrective action based on performancemetrics on a transaction exchange platform, such as transaction exchangeplatform 320. Examples of performance metrics include, for example, howlong it takes a transaction to complete an associated workflow fromstart to finish. As will be discussed, performance metrics may bemeasured at any suitable level, for example per transaction, per groupof transaction, within a time frame, within a sample, and the like.Method 1300 may be performed by any suitable computing device and/orcombination of computing devices, referred to as the system implementingmethod 1300.

At step 1305, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage.

At step 1310, the watchdog microservice may track progress oftransaction objects on the SDP through the microservices and workflowsassociated with a transaction type of the transaction object, asdescribed above with respect to FIG. 12 .

At step 1315, the watchdog microservice may determine one or moreperformance metrics associated with the transaction exchange platform,one or more workflows, one or more microservices, types of transactions,groups of transactions, individual transactions, and/or any suitablegranularity. The watchdog microservice may record how long it takes atransaction to move through its corresponding workflow, frommicroservice to microservice. This time may be recorded against upperand/or lower control limits with a rolling time period. The time periodmay be taken into account and normalized against business cycles (forexample: weekends are different than work days and certain hours of thework day look very different). Other metrics may be considered besidesprocessing time, such as throughput (volume), error rates, approve/denyrates, paths taken in branching workflows, and/or any other suitablemetric.

Metrics may be tracked at any desired level of granularity. For example,the watchdog microservice may track how long transaction take toprogress through the ACH workflow, and may assess whether this is withinhistorical performance ranges. Similarly, the watchdog microservice maytrack how long a particular microservice takes to process transactionsover the last five minutes and determine when this rises above a warninglevel, which may indicate a problem with the microservice. The watchdogmicroservice may determine baseline performance metrics for thetransaction exchange platform, workflows, microservices, and the like.Current metrics may be compared to these baseline metrics to determineand address abnormal performance.

At step 1320, the watchdog microservice may determine at least onerecommended action based on the performance metrics. Many correctiveactions may be recommended by the watchdog microservice, which mayflexibly adapt and learn suitable processes for responding to abnormalsystem conditions. A common recommended corrective action may be tocommand replay of an earlier workflow stage for a transaction or groupof transactions. Working with the snapshot microservice, the watchdogmicroservice can cause a transaction object to revert to an earlierstate, where the reversion to the current workflow stage of thetransaction object would cause it to be processed again by anappropriate microservice. Where a particular microservice is showingperformance abnormalities across a range of transactions, the watchdogmicroservice may determine that the particular microservice is havingproblems and recommend a suitable corrective action. As an example, thewatchdog microservice may determine that a dynamic reconfiguration toimplement alternate processing workflows, addressing the issuespresented by the particular microservice, represents a suitablecorrective action. The watchdog microservice may coordinate with theconfiguration interface to affect a reconfiguration of the workflow andthe corresponding microservices, potentially temporarily. In someimplementations, dynamic reconfiguration of a workflow, microservice, ortransaction may be recommended and implemented once successive replaysthrough the snapshot microservice have failed. Such reconfiguration mayaddress patterns of failure that become apparent from repeat errors fromthe microservices/workflows.

The watchdog microservice may implement other corrective actions aswell. For example, the watchdog microservice may utilize machinelearning techniques to self-optimize the workflows based on any suitablefeature, such as enhancing actions (rather than corrective action),security lockdown against intrusions, speed throughput, prioritizedrouting, restart, and most any other incident, administrative, ormanagement handling. The watchdog microservice provides a usefulinterface and allows machine learning collector agents to be deployed onthe transaction exchange platform to gather system state information foruse in optimizing and managing the transaction exchange platform. Othermetrics in addition to performance, security, resiliency,responsiveness, robustness, visibility, etc. may be considered by thewatchdog microservice, and the flexibility and comprehensive scope ofthe watchdog microservices may enable powerful management of thetransaction exchange platform.

At step 1325, the watchdog microservice may cause the recommended actionto be implemented. For example, the watchdog microservice may commandthe snapshot microservice to replay a workflow stage for the transactionobject. As another example, the watchdog microservice may command theconfiguration interface to dynamically reconfigure one or more workflowsand/or microservices based on the performance metric.

Subsequent to implementing the corrective action, the watchdogmicroservice may determine that successful processing is completed instep 1330. Or the watchdog microservice may determine that processinghas failed in step 1340, and may output the transaction for furtherreview (manually and/or automatically), and may generate anotherrecommended action, at step 1345.

According to some aspects, and as discussed above, the watchdogmicroservice may recommend as a corrective action replay of an earlierworkflow stage for a transaction or group of transactions. Working withthe snapshot microservice, the watchdog microservice can cause atransaction object to revert to an earlier state, where the reversion tothe current workflow stage of the transaction object would cause it tobe processed again by an appropriate microservice. This is describedfurther below with respect to FIG. 14 .

FIG. 14 depicts a flowchart illustrating an example method 1400 to trackperformance metrics and determine to replay a transaction on atransaction exchange platform, such as transaction exchange platform320. Method 1400 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1400. FIG. 14 may combine aspects of FIGS. 11 and 13, as explained further below.

At step 1405, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage. At step 1421, watchdogmicroservice 1420 may track program on the SDP of transaction objectsthrough microservice and workflows, as described with respect to FIG. 12above.

At step 1423, watchdog microservice 1420 may determine that atransaction object should replay a workflow stage. For example, asdiscussed above with respect to FIG. 13 , the watchdog microservice maydetermine that a transaction object did not correctly complete theworkflow step and/or that the microservice associated with the step isexperiencing abnormal performance issues. At step 1425, the watchdogmicroservice 1420 may command snapshot microservice 1430 to replay thetransaction object at the earlier workflow stage.

Snapshot microservice 1430 may store snapshot data records fortransaction objects on the SDP in steps 1431 and 1433, as discussedabove in FIGS. 10 and 11 . At step 1435, snapshot microservice 1430 mayreceive the command to replay the workflow step for the transactionobject from the watchdog microservice 1420. Snapshot microservice mayrollback the transaction object and reinject it to the SDP at steps 1437and 1439, in the manner described above with respect to FIG. 11 .

At step 1441, watchdog microservice 1420 may determine if the replayedworkflow stage was processed successfully. If it processed successful,processing may proceed to step 1443 where the transaction workflowcontinues.

If, at step 1441, watchdog microservice 1420 determines that processingdid not complete successfully, watchdog microservice 1420 may determinewhether a maximum number of rollbacks have been attempted at step 1445.The snapshot microservice 1430 and/or watchdog microservice 1420 maymaintain a counter of the number of rollback/replay attempts. The numberof rollback/replay attempts is less than a configurable threshold, thenprocessing may return to step 1425 where watchdog microservice 1420again commands snapshot microservice 1430 to replay the transaction.

If, at step 1445, watchdog microservice 1420 determines that a maximumnumber of replay attempts have already occurred, then watchdogmicroservice may determine a failure of the transaction to progressthrough the workflow stage at step 1447. At step 1449 the watchdogmicroservice 1420 may determine a further recommended action, such astriggering a dynamic reconfiguration of the work follow. This is shownfurther in FIG. 15 .

FIG. 15 depicts a flowchart illustrating an example method 1500 to trackperformance metrics and determine to replay a transaction on atransaction exchange platform, such as transaction exchange platform320. Method 1500 may be performed by any suitable computing deviceand/or combination of computing devices, referred to as the systemimplementing method 1500. FIG. 15 may combine aspects of FIGS. 11-14 ,as explained further below.

At step 1505, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage. At step 1521, watchdogmicroservice 1520 may track program on the SDP of transaction objectsthrough microservice and workflows, as described with respect to FIG. 12above.

At step 1522, the watchdog microservice may determine that a transactionobject should have a particular workflow stage replayed, and may orderthe snapshot microservice to replay the transaction as described in FIG.14 . Step 1522 may be optional, as watchdog microservice 1520 maydetermine to command dynamic reconfiguration even in the absence of areplayed transaction.

At step 1523, the watchdog microservice may determine that thetransaction exchange platform, one or more workflows, one or moremicroservices, or any other component should be modified. As discussedfurther above with respect to FIG. 13 , the watchdog microservice maymake this determination based on tracking one or more performancemetrics associated with the transaction exchange platform and/or any ofits components.

At step 1525, the watchdog microservice 1520 may command theconfiguration interface 1530 to reconfigure one or more microservices(and/or workflows, and/or any other component of the transactionexchange platform).

At step 1531, configuration interface 1530 may receive the command toreconfigure the microservices of the workflow, and may proceed throughsteps 1533 and 1535 to generate a configuration transaction object thatis pushed to the SDP to affect the desired reconfiguration, as describedabove with respect to FIG. 8 .

At step 1527, the watchdog microservice 1520 may command the snapshotmicroservice to replay the transaction object using the reconfiguredworkflow, if a particular transaction and/or group of transactions weresubject to erroneous and/or failed processing on the originalconfiguration.

At step 1529, the watchdog microservice 1520 may evaluate performance ofthe reconfigured workflow and continue to evaluate performance metricsassociated with aspects of the transaction exchange platform.

Thus, according to some aspects, a computer-implemented method maycomprise receiving a transaction object comprising transaction detailsand transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object and updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject. In response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed, the method may comprise: retrieving, bythe watchdog microservice and from the streaming data platform, thetransaction object based on determining that the current workflow stagehas changed and storing, by the watchdog microservice, workflow trackingdata corresponding to the transaction object and the changed currentworkflow stage.

The steps may further comprise determining, by the watchdogmicroservice, that the stored workflow tracking data corresponding tothe transaction object indicates that the transaction object completedeach stage of the workflow corresponding to the transaction type and, inresponse to determining that the stored workflow tracking data indicatesthat the transaction object completed each stage of the workflowcorresponding to the transaction type, removing the transaction objectfrom the streaming data platform and outputting the transaction objectand an indication that the transaction object has completed theprocessing corresponding to the workflow. The current workflow stage ofthe transaction object may comprise a data structure indicatingcompletion status of each respective step of a plurality of processingsteps associated with the workflow. The steps may further comprise, inresponse to the determining that the current workflow stage of thetransaction object has changed, determining, by the watchdogmicroservice, whether the current workflow stage of the transactionobject is valid based on the workflow associated with the transactiontype and, in response to determining that the current workflow stage ofthe transaction object is not valid, causing, by the watchdogmicroservice, the transaction object to be processed by one or moremicroservices associated with the workflow. The watchdog microservicemay store workflow tracking data in an in-memory database. The workflowtracking data may comprise a timestamp and an indication of the changeto the current workflow stage of the transaction object. The steps mayfurther comprise determining, by the watchdog microservice and based onthe workflow tracking data, at least one performance metric associatedwith the first microservice. The at least one performance metric maycorrespond to a single transaction object. The at least one performancemetric may correspond to a group of transaction objects over a period oftime. The steps may further comprise determining, by the watchdog microservice, that the at least one performance metric associated with thefirst microservice fails to satisfy at least one threshold performancevalue; and performing at least one action based on determining that theat least one performance metric fails to satisfy the at least onethreshold performance value. The steps may further comprise determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the workflow.

The steps may further comprise determining, by the watchdogmicroservice, that the at least one performance metric associated withthe workflow fails to satisfy at least one threshold performance value;and performing at least one action based on determining that the atleast one performance metric fails to satisfy the at least one thresholdperformance value. The steps may further comprise determining, by thewatchdog microservice and based on the workflow tracking data, at leastone baseline metric associated with the first microservice. The baselinemetric may correspond to processing performance by the firstmicroservice on a set of transaction objects over a period of time. Thesteps may further comprise determining, by the watchdog microservice andbased on the workflow tracking data, at least one performance metricassociated with a first transaction object processed by the firstmicroservice; determining that the at least one performance metricassociated with the first transaction object fails to satisfy athreshold relationship to the at least one baseline metric; andgenerating a recommended action to be taken on the first transactionobject. The recommended action may comprise causing the firsttransaction object to be re-processed by the first microservice. Therecommended action may comprise re-routing the first transaction objectto be processed by another microservice. The recommended action maycomprise changing the transaction type of the first transaction object.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details andtransaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; in response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed: retrieving, by the watchdog microserviceand from the streaming data platform, the transaction object based ondetermining that the current workflow stage has changed; and storing, bythe watchdog microservice, workflow tracking data corresponding to thetransaction object and the changed current workflow stage; determining,by the watchdog microservice, that the stored workflow tracking datacorresponding to the transaction object indicates that the transactionobject completed each stage of the workflow corresponding to thetransaction type; and in response to determining that the storedworkflow tracking data indicates that the transaction object completedeach stage of the workflow corresponding to the transaction type,removing the transaction object from the streaming data platform andoutput the transaction object and an indication that the transactionobject has completed the processing corresponding to the workflow. Thesteps may further comprise determining, by the watchdog microservice andbased on the workflow tracking data, at least one performance metricassociated with the first microservice. The steps may further comprisedetermining, by the watchdog microservice, that the at least oneperformance metric associated with the first microservice fails tosatisfy at least one threshold performance value; and generating arecommended action based on determining that the at least oneperformance metric fails to satisfy the at least one thresholdperformance value.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object, and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and retrieving, by afirst microservice and from the streaming data platform, the transactionobject based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise processing, by the firstmicroservice, the transaction object; updating the current workflowstage of the transaction object to a second workflow stage based oncompleting processing, by the first microservice, of the transactionobject; in response to determining, by a watchdog microservice and viathe streaming data platform, that the current workflow stage of thetransaction object has changed: retrieving, by the watchdog microserviceand from the streaming data platform, the transaction object based ondetermining that the current workflow stage has changed; and storing, bythe watchdog microservice, workflow tracking data corresponding to thetransaction object and the changed current workflow stage; determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the first microservice; andgenerating a graphic user interface display corresponding to the firstmicroservice and comprising the at least one performance metric.

And according to some aspects, a computer-implemented method maycomprise receiving a transaction object comprising transaction detailsand transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and inresponse to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice.

The steps may further comprise polling, by the snapshot microservice,the streaming data platform to retrieve transactions matching aninitialization stage. Transactions may be added to the streaming dataplatform in the initialization stage. The initialization stage may beassociated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object;determining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with addenda data of thetransaction object has changed after the transaction object has left theinitialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data. The snapshot microservice may cause the firstmicroservice to repeat processing of the transaction object based on thesnapshot data corresponding to the transaction object from prior to thestart of the processing by the first microservice. Causing the firstmicroservice to repeat processing of the transaction object may compriseregenerating, by the snapshot microservice, the transaction object basedon snapshot data corresponding to the transaction object from prior tothe start of the processing by the first microservice; and returning theregenerated transaction object to the streaming data platform. Thecurrent workflow stage of the regenerated transaction object may be setto the first workflow stage. The steps may further comprise determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the first microservice.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thefirst microservice fails to satisfy at least one performance thresholdvalue. The at least one performance metric may correspond to a singletransaction object. The at least one performance metric may correspondto a group of transaction objects over a period of time. The steps mayfurther comprise determining, by the watchdog microservice and based onthe workflow tracking data, at least one baseline metric associated withthe first microservice. The baseline metric may correspond to processingperformance by the first microservice on a set of transaction objectsover a period of time. The steps may further comprise determining, bythe watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with a first transaction objectprocessed by the first microservice. Determining that the processing, bythe first microservice, of the transaction object did not completesuccessfully may be based on determining that the at least oneperformance metric associated with the first transaction object fails tosatisfy a threshold relationship to the at least one baseline metric.The steps may further comprise determining a number of times that thetransaction object has undergone processing by the first microservice;in response to determining that the number of times that the transactionobject has undergone processing by the first microservice exceeds athreshold value, rejecting the transaction object as having failedprocessing associated with the first microservice; and determining acorrective action for the transaction object based on rejecting thetransaction object. The corrective action may comprise re-routing thefirst transaction object to be processed by another microservice. Thecorrective action may comprise changing the transaction type of thetransaction object. The corrective action may comprise changing theindication of the workflow corresponding to the transaction type of thetransaction object.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details, addendadata, and transaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and polling, by asnapshot microservice, the streaming data platform to retrievetransactions matching an initialization stage. Transactions may be addedto the streaming data platform in the initialization stage. Theinitialization stage may be associated with the snapshot microservice.The steps may further comprise retrieving, by the snapshot microserviceand from the streaming data platform, the transaction object based onthe current workflow stage matching the initialization stage; storing,by the snapshot microservice, snapshot data corresponding to thetransaction object; and processing, by a first microservice, thetransaction object on the streaming data platform based on the currentworkflow stage matching a first workflow stage. The first workflow stagemay be associated with the first microservice based on the workflowcorresponding to the transaction type. The steps may further comprisedetermining, by the snapshot microservice and via the streaming dataplatform, that at least one value associated with the addenda data ofthe transaction object has changed after the transaction object has leftthe initialization stage; and storing, by the snapshot microservice,snapshot data corresponding to the changed at least one value associatedwith the addenda data; updating the current workflow stage of thetransaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and causing the first microservice to repeat processing ofthe transaction object based on the snapshot data corresponding to thetransaction object captured by a snapshot microservice.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails, addenda data, and transaction metadata. The transactionmetadata may comprise an indication of a workflow corresponding to atransaction type of the transaction object, and a current workflow stageof the transaction object. The workflow corresponding to the transactiontype may comprise a plurality of processing steps required to approve agiven transaction of the transaction type. The steps may furthercomprise adding the transaction object to a streaming data platform. Thetransaction object may be added to the streaming data platform in aninitialization stage. The steps may further comprise polling, by thesnapshot microservice, the streaming data platform to retrievetransactions matching the initialization stage. The initialization stagemay be associated with the snapshot microservice. The steps may furthercomprise retrieving, by the snapshot microservice and from the streamingdata platform, the transaction object based on the current workflowstage matching the initialization stage; storing, by the snapshotmicroservice, snapshot data corresponding to the transaction object; andprocessing, by the first microservice, the transaction object on thestreaming data platform based on the current workflow stage matching afirst workflow stage. The first workflow stage may be associated withthe first microservice based on the workflow corresponding to thetransaction type. The steps may further comprise determining, by thesnapshot microservice and via the streaming data platform, that at leastone value associated with addenda data of the transaction object haschanged after the transaction object has left the initialization stage;storing, by the snapshot microservice, snapshot data corresponding tothe changed at least one value associated with the addenda data;updating the current workflow stage of the transaction object to asecond workflow stage based on completing processing, by the firstmicroservice, of the transaction object; and in response to determining,by a watchdog microservice and via the streaming data platform, that thecurrent workflow stage of the transaction object has changed, storingworkflow tracking data corresponding to the transaction object and thechanged current workflow stage; determining, by the watchdogmicroservice, that the processing, by the first microservice, of thetransaction object did not complete successfully; and causing the firstmicroservice to repeat processing of the transaction object based onsnapshot data corresponding to the transaction object captured by asnapshot microservice by: regenerating, by the snapshot microservice,the transaction object based on snapshot data corresponding to thetransaction object from prior to the start of the processing by thefirst microservice; and returning the regenerated transaction object tothe streaming data platform. The current workflow stage of theregenerated transaction object may be set to the first workflow stage.The steps may further comprise determining, by the watchdog microserviceand based on the workflow tracking data, at least one baseline metricassociated with the first microservice. The baseline metric maycorrespond to processing performance by the first microservice on a setof transaction objects over a period of time. The steps may furthercomprise determining, by the watchdog microservice and based on theworkflow tracking data, at least one performance metric associated withthe first transaction object processed by the first microservice.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thesingle transaction objects fails to satisfy a threshold relationship tothe at least one baseline metric.

According to some aspects, a computer-implemented method may comprisesteps comprising receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and reconfiguring the first microservice or a relatedsecond microservice based on determining that the processing, by thefirst microservice, of the transaction object did not completesuccessfully. The steps may further comprise causing the firstmicroservice to repeat processing of the transaction object based onsnapshot data corresponding to the transaction object captured by asnapshot microservice; and determining that the repeat processing of thetransaction object also did not complete successfully. Reconfiguring thefirst microservice or the related second microservice may be based ondetermining that the repeat processing of the transaction object failed.Reconfiguring the first microservice or a related second microservicemay comprise generating a configuration transaction object that may beconfigured to cause reconfiguration of the first workflow by causingreconfiguration of the first microservice. The configuration transactionobject may comprise transaction metadata that indicates a configurationworkflow and a current workflow stage of the configuration transactionobject. The steps may further comprise adding the configurationtransaction object to the streaming data platform; updating the currentworkflow stage of the configuration transaction object to the firstworkflow stage; retrieving, by the first microservice and from thestreaming data platform, the configuration transaction object based onthe current workflow stage matching the first workflow stage; andprocessing, by the first microservice, the configuration transactionobject to reconfigure the first microservice. Reconfiguring the firstmicroservice or the related second microservice may cause transactionobjects associated with the workflow to be dynamically re-routed.Reconfiguring the first microservice or the related second microservicemay comprise reconfiguring the first microservice to modify at least oneoperation that the first microservice performs on transaction objectsassociated with the workflow. Reconfiguring the first microservice orthe related second microservice may comprise reconfiguring the relatedsecond microservice to cause removal of the first microservice from theworkflow. The second related microservice may be a predecessormicroservice that proceeds the first microservice in the workflow. Thesteps may further comprise determining, by the watchdog microservice, atleast one performance metric associated with the first micro service.Determining that the processing, by the first microservice, of thetransaction object did not complete successfully may be based ondetermining that the at least one performance metric associated with thefirst microservice fails to satisfy at least one threshold performancevalue. The steps may further comprise determining, by the watchdogmicroservice and based on the workflow tracking data, at least oneperformance metric associated with the workflow. Determining that theprocessing, by the first microservice, of the transaction object did notcomplete successfully may be based on determining that the at least oneperformance metric associated with the workflow fails to satisfy atleast one threshold performance value.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. Each microservice of the plurality ofmicroservices may be configured to watch for transactions on thestreaming data platform in a corresponding workflow stage based on aplurality of workflows corresponding to a plurality of transactiontypes. The memory may store instructions that, when executed by the atleast one processor, cause the platform to perform steps includingreceiving a transaction object comprising transaction details andtransaction metadata. The transaction metadata may comprise anindication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by thefirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and inresponse to determining, by a watchdog microservice and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; and reconfigure the first microservice based ondetermining that the processing, by the first microservice, of thetransaction object did not complete successfully by generating aconfiguration transaction object that may be configured to causereconfiguration of the first microservice and adding the configurationtransaction object to the streaming data platform. The steps may furthercomprise causing the first microservice to repeat processing of thetransaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice; and determiningthat the repeat processing of the transaction object also did notcomplete successfully. Reconfiguring the first microservice may be basedon determining that the repeat processing of the transaction objectfailed. Reconfiguring the first microservice may cause transactionobjects associated with the workflow to be dynamically re-routed.Reconfiguring the first microservice may comprise reconfiguring thefirst microservice to modify at least one operation that the firstmicroservice performs on transaction objects associated with theworkflow. Reconfiguring the first microservice may comprisereconfiguring a related second microservice to cause the removal of thefirst microservice from the workflow. The second related microservicemay be a predecessor microservice that proceeds the first microservicein the workflow. The steps may further comprise determining, by thewatchdog microservice, at least one performance metric associated withthe first micro service. Determining that the processing, by the firstmicroservice, of the transaction object did not complete successfullymay be based on determining that the at least one performance metricassociated with the first microservice fails to satisfy at least onethreshold performance value. The steps may further comprise determining,by the watchdog microservice and based on the workflow tracking data, atleast one performance metric associated with the workflow. Determiningthat the processing, by the first microservice, of the transactionobject did not complete successfully may be based on determining thatthe at least one performance metric associated with the workflow failsto satisfy at least one threshold performance value.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving a transaction object comprising transactiondetails and transaction metadata. The transaction metadata may comprisean indication of a workflow corresponding to a transaction type of thetransaction object and a current workflow stage of the transactionobject. The workflow corresponding to the transaction type may comprisea plurality of processing steps required to approve a given transactionof the transaction type. The steps may further comprise adding thetransaction object to a streaming data platform; and processing, by afirst microservice, the transaction object on the streaming dataplatform based on the current workflow stage matching a first workflowstage. The first workflow stage may be associated with the firstmicroservice based on the workflow corresponding to the transactiontype. The steps may further comprise updating the current workflow stageof the transaction object to a second workflow stage based on completingprocessing, by the first microservice, of the transaction object; and,in response to determining, by a watchdog micro service and via thestreaming data platform, that the current workflow stage of thetransaction object has changed, storing workflow tracking datacorresponding to the transaction object and the changed current workflowstage; determining, by the watchdog microservice, that the processing,by the first microservice, of the transaction object did not completesuccessfully; causing the first microservice to repeat processing of thetransaction object based on snapshot data corresponding to thetransaction object captured by a snapshot microservice; and determiningthat the repeat processing of the transaction object also did notcomplete successfully; and reconfiguring the first microservice or arelated second microservice, based on determining that the repeatprocessing of the transaction object also did not complete successfully.Reconfiguring the first microservice may comprise generating aconfiguration transaction object that may be configured to causereconfiguration of the first workflow by causing reconfiguration of thefirst microservice. The configuration transaction object may comprisetransaction metadata that indicates a configuration workflow, and acurrent workflow stage of the configuration transaction object.Reconfiguring the first microservice may further comprise adding theconfiguration transaction object to the streaming data platform;updating the current workflow stage of the configuration transactionobject to the first workflow stage; retrieving, by the firstmicroservice and from the streaming data platform, the configurationtransaction object based on the current workflow stage matching thefirst workflow stage; and processing, by the first microservice, theconfiguration transaction object to reconfigure the first microservice.Reconfiguring the first microservice or the related second microservicemay cause transaction objects associated with the workflow to bedynamically re-routed.

Consensus Key Locking

The transaction exchange platform described herein is designed tochoreograph a series of events into payment flows (sagas). Thetransaction exchange platform choreographs the payment flows using aplurality of microservices that are designed to process streaming dataand handle duplicate content. Additionally, the transaction exchangeplatform may also include built-in replay capabilities to ensure thatsaga flows progress through to completion. Because large sums of moneyare regularly processed by the transaction exchange platform, thetransaction exchange platform needs to be a highly available system. Toaccomplish high availability, several instances of the transactionexchange platform may execute concurrently, in different geographicallocations. Each instance of the transaction exchange platform may bereferred to as a cluster, or a single cluster.

Some transactions handled by the transaction exchange platform areextremely sensitive to duplicate data. Because of this, the transactionexchange platform must guarantee idempotent transactions have theability to lock a key, resource, and/or data, across all instances, inall regions. However, existing solutions suffer from shortcomings. Forexample, traditional write forward mechanisms, such as RedisActive-Active, have a window where cross-region writes eventually becomeconsistent and could allow instances in both regions to believe thatthey own the lock, resulting in the potential for duplicate processing.Furthermore, existing database solutions are unable to guaranteeidempotent transactions have the ability to lock a key, resource, and/ordata, across all instances, in all regions. In this regard, relationaldatabases, such as AWS Aurora (MySQL Multi-mater), have performanceissues with frequent conflict resolution, which is to be expected whenprocessing replicated streaming data in multiple regions. Otherdatabases, like Cockroach DB, etcd, RedisRaft, and the like, may offerconsensus protocol solutions, like Raft, which may provide a lockingmechanism. However, these other databases may attempt to version eachupdate, which would require consensus overhead that would increaselatency. Additionally or alternatively, these other databases may allowsubsequent changes to be made provided there was not a simultaneouswrite conflict. Another problem is that these other databases tend tohold a limited amount of data due to the synchronization of snapshots.Moreover, the databases that implement consensus protocols traditionallysolve for a single instance lock acquisition and are, therefore,relatively slow and unable to scale. In conclusion, database solutionsthat use the consensus protocol for all read and write transactionswould incur too much overhead and latency to be able to functioneffectively in a production environment.

The present disclosure overcomes the shortcomings of prior solutions byproviding a locking microservice that enables lock acquisition consensusacross a geographically distributed system, with fast read/write accessto corresponding value data stored in the region processing thetransaction. The locking microservice may leverage the consensusprotocol only when acquiring a lock on a key value and handles all otheraspects of data access with a local fast write forward system. This isan improvement over existing systems since leveraging consensus protocolonly when acquiring a lock on a key value, and handling all otheraspects of data access with a fast write forward system, guaranteesidempotent transactions in a system with data replicated across regions.By limiting the consensus protocol interactions only to writing uniquekeys—which is done once per transaction, the locking microservicedescribed herein improves performance by storing metadata and/orapplication-related state details in the local cache system after thelock is acquired. This improves the performance and reliability of thedistributed locking mechanism described herein. Moreover, performancemay be further improved by sharding data across different consensusclusters and managing leader and quorum placement in the region with thehighest volume of traffic.

FIG. 16 illustrates a transaction processing system 1600 that may besimilar to transaction processing systems 300, 600, and/or 900 of FIGS.3A, 6, and 9 , respectively. Relative to systems 300, 600, and/or 900,transaction processing system 1600 may add locking microservice 1610, alocal storage system 1615, and a distributed lock manager 1620. Althoughnot shown in FIG. 16 , transaction exchange platform 320 may be one ofseveral transaction exchange platforms associated with transactionprocessing system 1600. In this regard, each one of the severaltransaction exchange platforms may be associated with a geographicregion.

Locking microservice 1610 may operate on transaction exchange platform320 to acquire one or more locks on key values, data, and/or resourceson behalf of the plurality of microservices (e.g., first microservice331, second microservice 332, third microservice 333, . . . nthmicroservice 334) executing on transaction exchange platform 320.Several instances of locking microservice 1610 may exist in transactionprocessing system 1600, with each instance being associated with atransaction exchange platform located in a different geographic region.

According to one embodiment, locking microservice 1610 may receive arequest for a lock for a first resource, for example, first microservice331. As noted above, the first resource may be an entry in a database.The entry may be determined based on one or more key values. In responseto receiving the request, locking microservice 1610 may determinewhether a lock exists for the first resource. Locking microservice 1610may determine whether a lock exists for the first resource by querying alocal data structure, such as local storage system 1615. In this regard,local storage system 1615 may be cache system associated with thetransaction exchange platform 320. In some instances, local storagesystem 1615 is a fast write forward mechanism, like Redis. If lockingmicroservice 1610 determines that a lock exists for the first resource,locking microservice 1610 may notify first microservice 331. In someinstances, locking microservice 1610 may attempt to acquire the lock forthe first resource periodically. When locking microservice 1610determines that a lock does not exist for the first resource, lockingmicroservice 1610 may transmit an inquiry to distributed lock manager1620 to determine whether a lock exists for the first resource. In thisregard, another microservice executing on a different transactionexchange platform, located in a different geographic region, may own alock on the first resource. Distributed lock manager 1620 may beassociated with one or more databases. As will be discussed in greaterdetail below, distributed lock manager 1620 may invoke a consensusprotocol to determine whether to grant a lock on the first resource.Locking mechanism 1610 may receive a response to the inquiry. Similar tothe request made to local storage system 1615, locking microservice 1610may attempt to acquire the lock for the first resource periodically, forexample, if the response indicates that a lock exists for the firstresource. However, when a lock does not exist for the first resource,locking microservice 1610 may send (e.g., transmit) a request for a lockfor the first resource to distributed lock manager 1620. Distributedlocking manager 1620 may then send (e.g., transmit) the lock for thefirst resource to locking microservice 1610. Upon being granted thelock, locking microservice 1610 may notify first microservice 331 that alock for the first resource has been acquired. Additionally, lockingmicroservice 1610 may send (e.g., transmit) a notification to one ormore locking microservices, each associated with a transaction exchangeplatform of a different geographic location, indicating that firstmicroservice 331 has acquired a lock for the first resource. Thenotification may comprise a synchronization signal. Similarly, lockingmicroservice 1610 may send (e.g., transmit) a synchronization signalindicating an updated value for the first resource, for example, afterfirst microservice 331 has processed the transaction. Additionally,locking microservice 1610 may send (e.g., transmit) a request to releasethe lock, for example, based on a determination that first microservice331 has completed processing of a transaction object using the firstresource.

FIG. 17 depicts an illustrative method 1700 for obtaining a lock on aresource according to one or more aspects of the disclosure. Method 1700may be performed by any suitable computing device and/or combination ofcomputing devices, referred to as the system implementing method 1700.

As noted above, a transaction exchange platform may receive a firsttransaction object corresponding to a first payment transaction. Asnoted above, first transaction exchange platform may comprise one ormore server clusters, with each of the one or more server clusters beingassociated with a geographic region. The transaction exchange platformmay comprise a single streaming data platform (SDP) that is accessibleby the one or more server clusters. Further, each of the one or moreserver clusters may comprise microservices, such as microservices forprocessing the transaction object according to a workflow. Additionally,each of the one or more server clusters may also include microservicesfor managing the processing of the transaction objects, such as thewatchdog microservice, the snapshot microservice, the lockingmicroservice, etc. There may be multiple instances of each microservicerunning in all regions. As shown in FIG. 17 , the transaction exchangeplatform comprises a first geographic region 1701 and a secondgeographic region 1702. The second geographic region may be differentfrom the first geographic region. In response to receiving thetransaction object, a microservice from either region (e.g., firstgeographic region 1701, second geographic region 1702) may retrieve aplurality of transaction objects, including the first transactionobject, from the SDP. As noted above, the microservice may compare aworkflow of each of the plurality of transaction objects to the workflowassociated with the microservice. If the workflow of the transactionobject matches the workflow associated with the microservice, themicroservice may process the transaction object.

Returning to FIG. 17 , first microservice 331 may retrieve a pluralityof transaction objects, including the first transaction object, from theSDP. First microservice 331 may compare a workflow of the firsttransaction object to the workflow associated with first microservice331. When the workflow of the first transaction object matches theworkflow associated with first microservice 331, first microservice 331may process the first transaction object. While processing the firsttransaction object, first microservice may determine that the processingof the first transaction object requires use of a first resource, suchas a database entry, a table entry, a key value associated with adatabase entry or a table entry, etc. In step 1705, first microservice331 may send a request for a lock on the first resource. Lockingmicroservice 1610, associated with the first geographic region 1701, mayreceive the request for the lock for the first resource from firstmicroservice 331. In step 1715, first locking microservice 1610 maydetermine whether a lock exists for the first resource. Determiningwhether a lock exists for the first resource may comprise querying alocal data structure, such as first local storage 1615. As noted above,first local storage 1615 may be similar to the local storage system1615, described in FIG. 16 . In step 1725, first locking microservice1610 may receive a response to the query. As shown in FIG. 17 , theresponse to first locking mechanism 331 indicates that a lock does notexist for the first resource. Based on a determination that a lock doesnot exist for the first resource, first locking microservice 331 maysend (e.g., transmit) a request for a lock on the first resource todistributed lock manager 1610, in step 1735. In some examples, firstlocking microservice 331 may send an inquiry to distributed lock manager1610 to determine whether a lock exists for the first resource. Therequest for the lock on the first resource may be sent in response toreceiving a response from distributed lock manager 1610 that indicatesthat a lock does not exist for the first resource.

In response to receiving the request for the lock from first lockingmicroservice 331, distributed lock manager 1620 may invoke a consensusprotocol to determine whether to grant the lock on the first resource tofirst microservice 331. According to some examples, the quorum for theconsensus protocol may be located in the same region where the mosttraffic is occurring. Requests from other regions may be routed to theregion where the most traffic is occurring, for example, using DNSand/or latency-based rules. By routing requests from other regions tothe region with quorum, the present disclosure can avoid having toresolve consensus across elector nodes in different geographic regions.In some instances, distributed lock manager 1620 may query each of theone or more server clusters to render a determination as to whether togrant the lock on the first resource to first microservice 331. Ifdistributed lock manager 1620 receives responses indicating that thelock should not be granted to first microservice 331, distributed lockmanager 1620 may deny the request for the lock on the first resource.Similarly, if distributed lock manager 1620 receives less than athreshold amount of responses indicating that the lock should be grantedto first microservice 331 (e.g., <50%), distributed lock manager 1620may deny the request for the lock on the first resource. However, whendistributed lock manager 1620 receives more than a threshold amount ofresponses indicating that the lock should be granted to firstmicroservice 331 (e.g., >50%), distributed lock manager 1620 may grantthe request for the lock. In step 1745, distributed lock manager 1620may send a response to first locking microservice 1610. The response mayindicate that the lock on the first resource has been granted. Firstlocking service 1610 may receive the response. In step 1747, firstlocking microservice 1610 may send (e.g., transmit), to firstmicroservice 331, an indication that a lock for the first resource hasbeen acquired. In response to receiving the indication, firstmicroservice 331 may process the first transaction object using thefirst resource. Processing the first transaction object may cause firstmicroservice 331 to generate an updated value of the first resource.Additionally or alternatively, processing the first transaction objectmay include updating a region associated with the first transactionobject and/or updating the workflow stage associated with the firsttransaction object. In FIG. 17 , first microservice 331 may update theregion associated with the first transaction object to indicate firstgeographic region 1701. After obtaining the lock, first lockingmicroservice 1610 may synchronize the lock with the local storagesystems associated with each of the one or more server clusters. Forexample, first locking microservice 1610 may set the lock in first lockstorage system 1615, in step 1755. Additionally or alternatively,setting the lock may comprise updating state details, such as amicroservice processing the first transaction object, a geographicregion processing the first transaction object, etc., associated withthe processing of the first transaction object. Similarly, first lockingmicroservice 1610 may send a synchronization signal to the other localstorage systems, in step 1760. The synchronization signal may indicatethat first microservice 331 has acquired a lock on the first resource.Additionally or alternatively, the synchronization signal may compriseone or more state details associated with the processing of the firsttransaction object.

At, or around, the same time first microservice 331 sends the requestfor the lock on the first resource, second microservice 1731 may issue asimilar request for the first resource, in step 1710. As shown in FIG.17 , second microservice 1731 may be executing in second geographicregion 1702. It will be appreciated that second microservice 1731 mayexecute in the same geographic region (e.g., first geographic region1701) as first microservice 331. In this regard, two or more entitiesexecuting in separate threads of the same application or separatecontainers in the same region may contend for a lock on the sameresource key. Second microservice 1731 may send the request for the lockon the first resource to second locking microservice 1703. Secondlocking microservice 1703 may query second local storage 1707 todetermine whether a lock exists on the first resource. Second localstorage 1707 may be similar to first local storage 1615. Because firstmicroservice 331 had not yet acquired the lock on the first resource,second local storage 1707 may send a response indicating that a lockdoes not exist for the first resource, in step 1730. In response toreceiving the response from second local storage 1707, second lockingmicroservice 1703 may send (e.g., transmit) a request for a lock on thefirst resource to distributed lock manager 1610, in step 1740. As shownin FIG. 17 , first locking microservice 1610 may beat the second lockingmicroservice 1703 in the request for the first resource. Accordingly,distributed lock manager 1620 may deny the request from second region1702, in step 1750. In this regard, distributed lock manager 1620 maysend the denial to second locking microservice 1703. Second lockingmicroservice 1703 may receive the denial. In step 1753, second lockingmicroservice 1703 may send an indication to second microservice 1731that the lock for the first resource was denied.

In some instances, the requests made in steps 1735 and 1740 may bereceived at, or about, the same time, thereby creating a race condition.As discussed above, distributed lock manager 1620 may invoke a consensusprotocol amongst the one or more server clusters to resolve the racecondition. Consensus may be performed, for example, when no prior dataexists for a payment id, after a lock has timed out, and/or a processdetermined that a lock is stale and forced unlocked it such that thereis contention for a new lock on the resource. Lock state details do notrequire consensus and may be written locally. In the examples describedabove, distributed lock manager 1620 may grant the lock to the regionindicated by a majority of the one or more server clusters.

While first microservice 331 owns the lock on the first resource, othermicroservices may request access to the first resource. Additionally oralternatively, the other microservices may request a lock on the firstresource. The request for the lock may be so that another microservicecan process a transaction object using the first resource. Additionallyor alternatively, the request for the lock may be to check on the statusof the first resource. That is, another microservice, such as secondmicroservice 1731, may request a lock on the first resource to determinewhether first microservice 331 has released the lock on the firstresource.

Returning to FIG. 17 , and specifically step 1765, second microservice1731 may request a lock for the first resource, for example, while firstmicroservice 331 owns the lock on the first resource. Secondmicroservice 1731 may issue (e.g., send, transmit) the request to secondlocking microservice 1703. In response to receiving the request, secondlocking microservice 1703 may query second local storage 1707 todetermine whether a lock exists for the first resource, for example, instep 1770. Second local storage 1707 may receive the query and determinewhether a lock exists for the first resource. In response to thesynchronization signal sent by first locking microservice 1710, secondlocal storage 1707 may include a database entry indicating that a lockexists for the first resource. In step 1775, second local storage maysend a response to second locking microservice 1703. As shown in FIG. 17, the response sent in step 1775 may indicate that the lock alreadyexists. In step 1780, second locking microservice 1703 may indicate thatthe lock exists and any request issued by second microservice 1731 for alock on the first resource may be denied.

The locking procedures described in FIG. 17 ensure the integrity of databeing processed by the transaction exchange platform. Additionally, thelocking procedures, and in particular, the combination of the fast localstorage and the distributed lock manager provides an improvement overprior art systems, which would require the requesting platform to polleach of the one or more server clusters individually to obtain a lock ona resource. By providing a local fast cache storage to manage locks anda centralized lock manager, the locking mechanisms described hereinimprove the speed with which distributed processing occurs, whileensuring that competing processing platforms do not corrupt data.

First microservice 331 may own the lock on the first resource untilfirst microservice 331 completes processing of the first transactionobject using the first resource. When processing of the firsttransaction object using the first resource is complete, firstmicroservice 331 may release the lock on the first resource. FIG. 18depicts an illustrative method 1800 for releasing a lock on a resourceaccording to one or more aspects of the disclosure. Method 1800 may beperformed by any suitable computing device and/or combination ofcomputing devices, referred to as the system implementing method 1800.

After completing processing of first transaction object, firstmicroservice 331 may update a value of the first resource. Updating thevalue may comprise writing one or more pieces of information to adatabase entry. In step 1810, first microservice 331 may transmit theupdated value to first local storage 1615. The updated value may be anupdated value to be stored in a database entry of the first resource.Additionally or alternatively, the updated value may include statedetails associated with the processing of the first transaction object.For example, the updated value may comprise a geographic regionprocessing the first transaction object. Additionally or alternatively,the updated value may comprise intermediate processing results of thefirst transaction object.

In step 1815, first local storage 1615 may send (e.g., transmit) asynchronization signal to second locking microservice 1715. Thesynchronization signal may indicate the updated value for the firstresource. First local storage 1615 may send the synchronization signalto the local storage associated with each of the one or more serverclusters. In step 1820, first microservice 331 may send (e.g., transmit)a request to release the lock on the first resource to first lockingmicroservice 1610. As noted above, the request to release the lock onthe first resource may be based on a determination that firstmicroservice 331 has completed processing of the first transactionobject using the first resource. In step 1825, first lockingmicroservice 1610 may send (e.g. transmit) a request to release the lockon the first resource to distributed lock manager 1620. In someexamples, the request to release the lock may include one or moreupdated values for the first resource. In response to receiving therequest to release the lock on the first resource, distributed lockmanager 1620 may send a synchronization signal to each local storage ofthe one or more server clusters, in step 1830. The synchronizationsignal may update the status of the lock on the first resource.Additionally or alternatively, the synchronization signal may update thevalue of the first resource and step 1815 may be skipped. After the lockon the first resource may be skipped, other microservices may obtain alock on the first resource.

In step 1835, second microservice 1731 may send a request for a lock onthe first resource. Second locking microservice 1703 may receive therequest for the lock for the first resource from second microservice1731. In step 1840, second locking microservice 1703 may determinewhether a lock exists for the first resource by querying second localstorage 1707. In step 1845, second local storage 1715 may send (e.g.transmit) a response to second locking microservice 1703 indicating thata lock does not exist on the first resource. In step 1845, secondlocking microservice 1703 may send (e.g., transmit) a request for a lockon the first resource to distributed lock manager 1620. Distributed lockmanager 1620 may receive the request for the lock on the first resource.Similar to the techniques described above, distributed lock manager 1620may invoke a consensus protocol to determine whether to grant the lockto second microservice 1731. Distributed lock manager 1620 may determinethat the request for the lock should be granted to second microservice1731. In step 1850, distributed lock manager 1620 may send (e.g.,transmit) an indication to second locking microservice 1703 that therequest for the lock on the first resource has been granted to secondmicroservice 1731. After receiving the lock, second locking microservice1703 may synchronize the lock with the local storage systems associatedwith each of the one or more server clusters. In step 1855, secondlocking microservice 1703 may initially set the lock in second lockstorage system 1715. In step 1860, second locking microservice 1610 maythen send a synchronization signal to the other local storage systems.The synchronization signal may indicate that second microservice 1731has acquired a lock on the first resource.

The techniques described above with respect to FIGS. 17 and 18 may beused to obtain and release locks on shared and/or commonly accessedresources, such as database entries, applications, etc. The use of thefast local storage and the consensus protocol by the distributed lockmanager resolves race conditions for resources quickly and ensures theintegrity of the data.

According to other embodiments, a computer-implemented method mayreceive, by a transaction exchange platform, a transaction objectcorresponding to a first payment transaction. The transaction exchangeplatform may comprise a first streaming data platform associated with afirst geographic region and a second stream data platform associatedwith a second geographic region. The computer-implemented method maydetermine, by the first microservice during processing of thetransaction object, that the processing of the transaction objectrequires use of a first resource, for example, in response to retrievinga plurality of transaction objects from the first streaming dataplatform and based on a determination that a workflow stage of thetransaction object matches a first workflow stage associated with afirst microservice. The first resource may be an entry in a database.The computer-implemented method may receive, by a locking microservicefrom the first microservice, a request for a lock for the firstresource. The computer-implemented method may determine, by the lockingmicroservice and based on querying a local data structure, whether alock exists for the first resource. The computer-implemented method maytransmit, by the locking microservice to a distributed lock manager, aninquiry whether a lock exists for the first resource, for example, basedon a determination that a lock does not exist for the first resource.The computer-implemented method may receive a response to the inquirythat indicates that a lock does not exist for the first resource. Thecomputer-implemented method may transmit, by the locking microservice tothe distributed lock manager and based on the response indicating that alock does not exist for the first resource, the request for a lock forthe first resource. The computer-implemented method may receive, by thelocking microservice from the distributed lock manager, a lock for thefirst resource. The lock may be granted based on a consensus protocolindicating that the lock should be granted to the first microservice.The computer-implemented method may transmit, by the lockingmicroservice to the first microservice, an indication that a lock forthe first resource has been acquired. The computer-implemented methodmay process, by the first microservice, a first transaction object usingthe first resource to generate an updated value of the first resource,for example, in response to receiving the indication. Processing thefirst transaction object may comprise updating a region associated withthe first transaction object and the workflow stage associated with thefirst transaction object. The computer-implemented method may transmit,by the locking microservice to a second locking microservice associatedwith the second streaming data platform, a synchronization signalindicating that the first microservice has acquired a lock for the firstresource. The computer-implemented method may transmit, by the lockingmicroservice to a second locking microservice associated with the secondstreaming data platform, a synchronization signal indicating the updatedvalue for the first resource. The computer-implemented method maytransmit, by the first microservice to the locking microservice, arequest to release the lock based on a determination that the firstmicroservice has completed processing of the first transaction objectusing the first resource.

The computer-implemented method may receive, by a second lockingmicroservice from a second microservice and during processing of thetransaction object by the first microservice, a request for a lock onthe first resource. The second locking microservice may be associatedwith the second streaming data platform and/or a second geographicregion. The computer-implemented method may determine, by the secondlocking microservice and based on querying a second local datastructure, that a lock exists for the first resource.

The computer-implemented method may receive, by a second lockingmicroservice from a second microservice and during processing of thetransaction object by the first microservice, a request for a lock onthe first resource. The second locking microservice may be associatedwith the second streaming data platform and/or a second geographicregion. The computer-implemented method may determine, by the secondlocking microservice and based on querying a second local datastructure, whether a lock exists for the first resource. Thecomputer-implemented method may transmit, by the second lockingmicroservice to the distributed lock manager, an inquiry whether a lockexists for the first resource, for example, based on a determinationthat a lock does not exist for the first resource. Thecomputer-implemented method may receive a response to the inquiry thatindicates that a lock exists for the first resource.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice, a first locking microservice, and/or asecond locking microservice. The memory may store instructions that,when executed by the at least one processor, cause the transactionexchange platform to receive, by a transaction exchange platform, atransaction object corresponding to a first payment transaction. Thetransaction exchange platform may comprise a first streaming dataplatform associated with a first geographic region and a second streamdata platform associated with a second geographic region. The memory maystore instructions that, when executed by the at least one processor,cause the transaction exchange platform to determine, by the firstmicroservice during processing of the transaction object, that theprocessing of the transaction object requires use of a first resource,for example, in response to retrieving a plurality of transactionobjects from the first streaming data platform and based on adetermination that a workflow stage of the transaction object matches afirst workflow stage associated with a first microservice. The firstresource may be an entry in a database. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to receive, by a locking microservicefrom the first microservice, a request for a lock for the firstresource. The memory may store instructions that, when executed by theat least one processor, cause the transaction exchange platform todetermine, by the locking microservice and based on querying a localdata structure, whether a lock exists for the first resource. The memorymay store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to transmit, by thelocking microservice to a distributed lock manager, an inquiry whether alock exists for the first resource, for example, based on adetermination that a lock does not exist for the first resource. Thememory may store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to receive a responseto the inquiry that indicates that a lock does not exist for the firstresource. The memory may store instructions that, when executed by theat least one processor, cause the transaction exchange platform totransmit, by the locking microservice to the distributed lock managerand based on the response indicating that a lock does not exist for thefirst resource, the request for a lock for the first resource. Thememory may store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to receive, by thelocking microservice from the distributed lock manager, a lock for thefirst resource. The lock may be granted based on a consensus protocolindicating that the lock should be granted to the first microservice.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to transmit, bythe locking microservice to the first microservice, an indication that alock for the first resource has been acquired. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to process, by the first microservice,a first transaction object using the first resource to generate anupdated value of the first resource, for example, in response toreceiving the indication. Processing the first transaction object maycomprise updating a region associated with the first transaction objectand the workflow stage associated with the first transaction object. Thememory may store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to transmit, by thelocking microservice to a second locking microservice associated withthe second streaming data platform, a synchronization signal indicatingthat the first microservice has acquired a lock for the first resource.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to transmit, bythe locking microservice to a second locking microservice associatedwith the second streaming data platform, a synchronization signalindicating the updated value for the first resource. The memory maystore instructions that, when executed by the at least one processor,cause the transaction exchange platform to transmit, by the firstmicroservice to the locking microservice, a request to release the lockbased on a determination that the first microservice has completedprocessing of the first transaction object using the first resource.

The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to receive, by asecond locking microservice from a second microservice and duringprocessing of the transaction object by the first microservice, arequest for a lock on the first resource. The second lockingmicroservice may be associated with the second streaming data platformand/or a second geographic region. The memory may store instructionsthat, when executed by the at least one processor, cause the transactionexchange platform to determine, by the second locking microservice andbased on querying a second local data structure, that a lock exists forthe first resource.

The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to receive, by asecond locking microservice from a second microservice and duringprocessing of the transaction object by the first microservice, arequest for a lock on the first resource. The second lockingmicroservice may be associated with the second streaming data platformand/or a second geographic region. The memory may store instructionsthat, when executed by the at least one processor, cause the transactionexchange platform to determine, by the second locking microservice andbased on querying a second local data structure, whether a lock existsfor the first resource. The memory may store instructions that, whenexecuted by the at least one processor, cause the transaction exchangeplatform to transmit, by the second locking microservice to thedistributed lock manager, an inquiry whether a lock exists for the firstresource, for example, based on a determination that a lock does notexist for the first resource. The memory may store instructions that,when executed by the at least one processor, cause the transactionexchange platform to receive a response to the inquiry that indicatesthat a lock exists for the first resource.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving, by a transaction exchange platform, atransaction object corresponding to a first payment transaction, whereinthe transaction exchange platform comprises a first streaming dataplatform associated with a first geographic region and a second streamdata platform associated with a second geographic region; in response toretrieving a plurality of transaction objects from the first streamingdata platform and based on a determination that a workflow stage of thetransaction object matches a first workflow stage associated with afirst microservice, determining, by the first microservice duringprocessing of the transaction object, that the processing of thetransaction object requires use of a first resource; receiving, by alocking microservice from the first microservice, a request for a lockfor the first resource; determining, by the locking microservice andbased on querying a local data structure, whether a lock exists for thefirst resource; based on a determination that a lock does not exist forthe first resource, transmitting, by the locking microservice to adistributed lock manager, an inquiry whether a lock exists for the firstresource; receiving a response to the inquiry, wherein the responsecomprises an indication that a lock does not exist for the firstresource; transmitting, by the locking microservice to the distributedlock manager and based on the response indicating that a lock does notexist for the first resource, the request for a lock for the firstresource; receiving, by the locking microservice from the distributedlock manager, a lock for the first resource, wherein the lock is grantedbased on a consensus protocol indicating that the lock should be grantedto the first microservice; transmitting, by the locking microservice tothe first microservice, an indication that a lock for the first resourcehas been acquired; and in response to receiving the indication,processing, by the first microservice, a first transaction object usingthe first resource to generate an updated value of the first resource.Those steps may also include transmitting, by the locking microserviceto a second locking microservice associated with the second streamingdata platform, a synchronization signal indicating that the firstmicroservice has acquired a lock for the first resource. The stepsfurther include transmitting, by the locking microservice to a secondlocking microservice associated with the second streaming data platform,a synchronization signal indicating the updated value for the firstresource. The steps also include transmitting, by the first microserviceto the locking microservice, a request to release the lock based on adetermination that the first microservice has completed processing ofthe first transaction object using the first resource. The steps maycomprise receiving, by a second locking microservice from a secondmicroservice and during processing of the transaction object by thefirst microservice, a request for a lock on the first resource, whereinthe second locking microservice is associated with the second streamingdata platform; and determining, by the second locking microservice andbased on querying a second local data structure, that a lock exists forthe first resource. The steps may further comprise receiving, by asecond locking microservice from a second microservice and duringprocessing of the transaction object by the first microservice, arequest for a lock on the first resource, wherein the second lockingmicroservice is associated with the second streaming data platform;determining, by the second locking microservice and based on querying asecond local data structure, whether a lock exists for the firstresource; based on a determination that a lock does not exist for thefirst resource, transmitting, by the second locking microservice to thedistributed lock manager, an inquiry whether a lock exists for the firstresource; and receiving a response to the inquiry, wherein the responsecomprises an indication that a lock exists for the first resource.

Occasionally, processing of a first transaction object may fail while alock is in place. FIGS. 19A and 19B depict an illustrative method 1900for resolving a lock when processing of a transaction that owns the lockfails according to one or more aspects of the disclosure. Method 1900may be performed by any suitable computing device and/or combination ofcomputing devices, referred to as the system implementing method 1900.

As noted above, first microservice 331 may retrieve a plurality oftransaction objects, including the first transaction object, from anSDP. After comparing a workflow of the first transaction object to theworkflow associated with first microservice 331, first microservice 331may process the first transaction object and, while processing the firsttransaction object, determine that the processing of the firsttransaction object requires use of a first resource.

In step 1905, first microservice 331 may send a request for a lock onthe first resource. Locking microservice 1610 may receive the requestfor the lock for the first resource from first microservice 331. In step1910, first locking microservice 1610 may determine whether a lockexists for the first resource, for example, by querying a local datastructure, such as first local storage 1615. In step 1915, first lockingmicroservice 1610 may receive a response to the query indicating that alock does not exist for the first resource. First locking microservice331 may then send (e.g., transmit) a request for a lock on the firstresource to distributed lock manager 1610, in step 1920. In response toreceiving the request for the lock from first locking microservice 331,distributed lock manager 1620 may invoke a consensus protocol todetermine whether to grant the lock on the first resource to firstmicroservice 331. When distributed lock manager 1620 receives more thana threshold amount of responses indicating that the lock should begranted to first microservice 331 (e.g., >50%), distributed lock manager1620 may grant the request for the lock and send a response to firstlocking microservice 1610, in step 1925. First locking service 1610 mayreceive the response. In step 1930, first locking microservice 1610 maynotify first microservice 331 that a lock for the first resource hasbeen acquired. Additionally, first locking microservice 1610 maysynchronize the lock with the local storage systems associated with eachof the one or more server clusters. For example, first lockingmicroservice 1610 may set the lock in first local storage system 1615,in step 1935. In step 1940, first local storage system 1615 may send asynchronization signal to update the lock status of the other localstorage systems (e.g., second local storage system 1707).

In step 1945, an error may occur while first microservice 331 processesthe first transaction object while owning the lock on the firstresource. For example, first microservice 331 may fail and/or crash,cause processing of the first transaction object to stall. In anotherexample, the error may be based on a predetermined amount of timeelapsing since the first lock was acquired without any updates to theworkflow status of the first transaction object. As described above,watchdog microservice 980 may generate workflow tracking records foreach transaction object on the transaction exchange platform 320, andmay store information indicating whether the transaction objectcompleted each step of the workflow along with timestamps and othersuitable metadata. Based on these tracking records, watchdogmicroservice 980 may determine that processing of the first transactionobject has failed. In response to determining that processing of thefirst transaction object has failed, watchdog microservice 980 mayattempt to re-generate the first transaction object locally (e.g., inthe first geographic region 1701), for example, using the process shownin FIG. 14 and described above. If the attempt to re-generate the firsttransaction object locally fails or processing of the first transactionobject fails again, method 1900 may proceed to step 1950.

In step 1950, watchdog microservice 980 may cause the lock on the firstlock to be released, for example, in response to determining thatprocessing of the first transaction object has failed. Watchdogmicroservice 980 may send a signal to distributed lock manager 1620,which may send signal to each local storage with an indication that thelock on the first resource should be released. Additionally oralternatively, watchdog microservice 980 may send a signal to each localstorage system indicating that the lock on the first resource should bereleased.

In step 1955, watchdog service 980 may transfer processing of the firsttransaction object from first microservice 331, in the first region1701, to second microservice 1731, in the second region 1702. Inaddition to transfer processing of the first transaction object,watchdog microservice 980 may also transfer state details associatedwith processing of the first transaction object. For example, if firstmicroservice 331 performed any processing of the first transactionobject using the first resource, the state details and processedtransaction details may be transferred to second microservice 1731.These state details may include updating a workflow stage associatedwith the first transaction object to indicate that processing of thefirst transaction object is being handled by second region 1702. Afterprocessing of the first transaction object has been transferred to thesecond region 1702, second microservice 1731 may acquire a lock on thefirst resource in order to complete processing of the first transactionobject.

In step 1960, second microservice 1731 may send a request for a lock onthe first resource. Second locking microservice 1703 may receive therequest for the lock for the first resource from second microservice1731. In step 1965, second locking microservice 1703 may determinewhether a lock exists for the first resource by querying second localstorage 1707. In step 1970, second local storage 1715 may send aresponse to second locking microservice 1703 indicating that a lock doesnot exist on the first resource. In step 1975, second lockingmicroservice 1703 may send (e.g., transmit) a request for a lock on thefirst resource to distributed lock manager 1620. Distributed lockmanager 1620 may receive the request for the lock on the first resource.In step 1980, distributed lock manager 1620 may send (e.g., transmit) anindication to second locking microservice 1703 that the request for thelock on the first resource has been granted to second microservice 1731,for example, based on a determination that the lock should be granted tosecond microservice 1731. In step 1985, second locking microservice 1703may set the lock in the second local storage 1707. In step 1990, secondlocking microservice 1610 may then send a synchronization signal to theother local storage systems that indicates that second microservice 1731has acquired a lock on the first resource. Second microservice 1731 maythen process the first transaction object using the first resource togenerate an updated value of the first resource.

According to other embodiments, a computer-implemented method mayreceive, by a transaction exchange platform, a transaction objectcorresponding to a first payment transaction. The transaction exchangeplatform may comprise a first geographic region and a second geographicregion different from the first geographic region. Thecomputer-implemented method may determine, by the first microservicewhile processing the transaction object, that the processing of thetransaction object requires use of a first resource, for example, inresponse to retrieving a plurality of transaction objects from the firststreaming data platform and based on a determination that a workflowstage of the transaction object matches a first workflow stageassociated with a first microservice. The first microservice may beassociated with the first geographic region. The computer-implementedmethod may acquire, by a first locking microservice associated with thefirst geographic region and based on a determination that the processingof the transaction object requires use of the first resource, a firstlock for the first resource. The computer-implemented method may acquirethe first lock for the first resource by receiving, by the first lockingmicroservice from the first microservice, a request for a lock for thefirst resource; transmitting, by the locking microservice to adistributed lock manager, an inquiry whether a lock exists for the firstresource based on a determination that a lock does not exist for thefirst resource in the local data structure; receiving, from thedistributed lock manager, a response indicating a lock does not existfor the first resource; transmitting, by the locking microservice to thedistributed lock manager and based on the response indicating that alock does not exist for the first resource, the request for a lock forthe first resource; and receiving, by the locking microservice from thedistributed lock manager, the first lock for the first resource, whereinthe lock is granted based on a consensus protocol indicating that thefirst lock should be granted to the first microservice.

The computer-implemented method may process, by the first microservice,the transaction object using the first resource, for example, inresponse to receiving the first lock. Processing of the transactionobject may comprise updating a workflow stage associated with thetransaction object. The updated workflow stage may be transmitted to thesecond geographic region when the transaction object is transferred. Thecomputer-implemented method may determine, by a watchdog microservice,that processing of the transaction object has failed. The determinationthat processing of the transaction object using the first resource hasfailed may be based on a predetermined amount of time elapsing since thefirst lock was acquired. The computer-implemented method may release, bythe watchdog microservice and based on a determination that processingof the transaction object using the first resource has failed, the firstlock from the first resource. The computer-implemented method maytransfer, by the watchdog microservice, processing of the firsttransaction object to the second geographic region. Thecomputer-implemented method may update a region associated with thefirst transaction object to the second geographic region, for example,in response to transferring the transaction object. Thecomputer-implemented method may acquire, by a second lockingmicroservice associated with the second geographic region and based on adetermination that the processing of the transaction object requires useof the first resource, a second lock for the first resource. Thecomputer-implemented method may process, by a second microservice, thetransaction object using the first resource to generate an updated valueof the first resource, for example, in response to receiving the secondlock. The computer-implemented method may transmit, by the secondlocking microservice, a request to release the lock, for example, basedon a determination that the second microservice has completed processingof the transaction object using the first resource.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice, a second microservice, a first lockingmicroservice, a second locking microservice, and/or a watchdogmicroservice. The memory may store instructions that, when executed bythe at least one processor, cause the transaction exchange platform toreceive, by a transaction exchange platform, a transaction objectcorresponding to a first payment transaction. The transaction exchangeplatform may comprise a first geographic region and a second geographicregion different from the first geographic region. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to determine, by the firstmicroservice while processing the transaction object, that theprocessing of the transaction object requires use of a first resource,for example, in response to retrieving a plurality of transactionobjects from the first streaming data platform and based on adetermination that a workflow stage of the transaction object matches afirst workflow stage associated with a first microservice. The firstmicroservice may be associated with the first geographic region. Thememory may store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to acquire, by afirst locking microservice associated with the first geographic regionand based on a determination that the processing of the transactionobject requires use of the first resource, a first lock for the firstresource. The memory may store instructions that, when executed by theat least one processor, cause the transaction exchange platform toacquire the first lock for the first resource by receiving, by the firstlocking microservice from the first microservice, a request for a lockfor the first resource; transmitting, by the locking microservice to adistributed lock manager, an inquiry whether a lock exists for the firstresource based on a determination that a lock does not exist for thefirst resource in the local data structure; receiving, from thedistributed lock manager, a response indicating a lock does not existfor the first resource; transmitting, by the locking microservice to thedistributed lock manager and based on the response indicating that alock does not exist for the first resource, the request for a lock forthe first resource; and receiving, by the locking microservice from thedistributed lock manager, the first lock for the first resource, whereinthe lock is granted based on a consensus protocol indicating that thefirst lock should be granted to the first microservice.

The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to process, bythe first microservice, the transaction object using the first resource,for example, in response to receiving the first lock. Processing of thetransaction object may comprise updating a workflow stage associatedwith the transaction object. The updated workflow stage may betransmitted to the second geographic region when the transaction objectis transferred. The memory may store instructions that, when executed bythe at least one processor, cause the transaction exchange platform todetermine, by a watchdog microservice, that processing of thetransaction object has failed. The determination that processing of thetransaction object using the first resource has failed may be based on apredetermined amount of time elapsing since the first lock was acquired.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to release, bythe watchdog microservice and based on a determination that processingof the transaction object using the first resource has failed, the firstlock from the first resource. The memory may store instructions that,when executed by the at least one processor, cause the transactionexchange platform to transfer, by the watchdog microservice, processingof the first transaction object to the second geographic region. Thememory may store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to update a regionassociated with the first transaction object to the second geographicregion, for example, in response to transferring the transaction object.The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to acquire, by asecond locking microservice associated with the second geographic regionand based on a determination that the processing of the transactionobject requires use of the first resource, a second lock for the firstresource. The memory may store instructions that, when executed by theat least one processor, cause the transaction exchange platform toprocess, by a second microservice, the transaction object using thefirst resource to generate an updated value of the first resource, forexample, in response to receiving the second lock. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to transmit, by the second lockingmicroservice, a request to release the lock, for example, based on adetermination that the second microservice has completed processing ofthe transaction object using the first resource.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving, by a transaction exchange platform, atransaction object corresponding to a first payment transaction, whereinthe transaction exchange platform comprises a first streaming dataplatform associated with a first geographic region and a second streamdata platform associated with a second geographic region different fromthe first geographic region; in response to retrieving a plurality oftransaction objects from the first streaming data platform and based ona determination that a workflow stage of the transaction object matchesa first workflow stage associated with a first microservice,determining, by the first microservice while processing the transactionobject, that the processing of the transaction object requires use of afirst resource, wherein the first microservice is associated with thefirst geographic region; acquiring, by a first locking microserviceassociated with the first geographic region and based on a determinationthat the processing of the transaction object requires use of the firstresource, a first lock for the first resource; determining, by awatchdog microservice, that processing of the transaction object hasfailed; releasing, by the watchdog microservice and based on adetermination that processing of the transaction object using the firstresource has failed, the first lock from the first resource;transferring, by the watchdog microservice, processing of the firsttransaction object to the second geographic region; acquiring, by asecond locking microservice associated with the second geographic regionand based on a determination that the processing of the transactionobject requires use of the first resource, a second lock for the firstresource; and, in response to receiving the second lock, processing, bya second microservice, the transaction object using the first resourceto generate an updated value of the first resource. The determinationthat processing of the transaction object using the first resource hasfailed may be based on a predetermined amount of time elapsing since thefirst lock was acquired.

The steps may include in response to receiving the first lock,processing, by the first microservice, the transaction object using thefirst resource, wherein processing the transaction object comprisesupdating a workflow stage associated with the transaction object,wherein the updated workflow stage is transmitted to the secondgeographic region when the transaction object is transferred. The stepsmay also include updating a region associated with the first transactionobject to the second geographic region in response to transferring thetransaction object. The steps may further comprise receiving, by thefirst locking microservice from the first microservice, a request for alock for the first resource; based on a determination that a lock doesnot exist for the first resource in the local data structure,transmitting, by the locking microservice to a distributed lock manager,an inquiry whether a lock exists for the first resource; receiving, fromthe distributed lock manager, a response indicating a lock does notexist for the first resource; transmitting, by the locking microserviceto the distributed lock manager and based on the response indicatingthat a lock does not exist for the first resource, the request for alock for the first resource; and receiving, by the locking microservicefrom the distributed lock manager, the first lock for the firstresource, wherein the lock is granted based on a consensus protocolindicating that the first lock should be granted to the firstmicroservice. The steps may also comprise transmitting, by the secondlocking microservice, a request to release the lock based on adetermination that the second microservice has completed processing ofthe transaction object using the first resource.

According to some aspects, and as discussed above, the watchdogmicroservice may recommend as a corrective action replay of an earlierworkflow stage for a transaction or group of transactions, for examplein response to determining that processing of the transaction or groupof transaction has failed and/or stalled. Working with the snapshotmicroservice, the watchdog microservice can cause a transaction objectto revert to an earlier state, where the reversion to the currentworkflow stage of the transaction object would cause it to be processedagain by an appropriate microservice. This is described further belowwith respect to FIG. 20 .

FIG. 20 depicts a flowchart illustrating an example method 2000 fordetermining to replay a transaction on a transaction exchange platform,such as transaction exchange platform 320. Method 2000 may be performedby any suitable computing device and/or combination of computingdevices, referred to as the system implementing method 2000. FIG. 20 maycombine aspects of FIGS. 10 and 11 , as explained further below.

At step 2005, the transaction exchange platform may receive atransaction object and add it to a SDP. The transaction object may beadded to the SDP in an initialization stage. At step 2021, watchdogmicroservice 2020 may track transaction objects as they progress throughmicroservices and workflows, as described with respect to FIG. 12 above.

At step 2023, watchdog microservice 2020 may determine that atransaction object should replay a workflow stage. For example, thewatchdog microservice 2020 may determine that a transaction object didnot correctly complete the workflow step and/or that the microserviceassociated with the step is experiencing abnormal performance issues. Inanother example, watchdog microservice 2020 may determine thatprocessing of a transaction object cannot progress within the timeframedefined by saga flow service level agreements in a single region and,therefore, issue the command that those transaction objects be replayedin other regions. At step 2025, the watchdog microservice 2020 maycommand snapshot microservice 2030 to replay the transaction object atthe earlier workflow stage.

Snapshot microservice 2030 may store snapshot data records fortransaction objects on the SDP in steps 2031 and 2033, as discussedabove in FIGS. 10 and 11 . At step 2035, snapshot microservice 2030 mayreceive the command to replay the workflow step for the transactionobject from the watchdog microservice 2020. Snapshot microservice mayrollback the transaction object and reinject it to the SDP at steps 2037and 2039, in the manner described above with respect to FIG. 11 . Insome instances, the microservice that previously processed thetransaction object may acquire the transaction object from the SDP andre-attempt processing of the transaction object. In these instances,watchdog microservice 2020 may not cause the microservice's lock on theresource to be released. Alternatively, watchdog microservice 2020 maycause the lock to be released. Accordingly, the microservice may have tore-acquire a lock on the resource using the processes described above,for example, when the microservice begins processing the transactionobject again. In yet another alternative, watchdog microservice 2020 maytransfer processing of the transaction object to a different region, instep 2041, as described above in FIGS. 19A and 19B. In step 2043,watchdog microservice 2020 may determine if the replayed workflow stagewas processed successfully. If it processed successful, processing mayproceed to step 2045 where the transaction workflow continues.

If, at step 2043, watchdog microservice 2020 determines that processingdid not complete successfully, watchdog microservice 2020 may determinea failure of the transaction to progress through the workflow stage atstep 2047. At step 2049, the watchdog microservice 2020 may determine afurther recommended action, such as triggering a dynamic reconfigurationof the workflow.

According to other embodiments, a computer-implemented method mayreceive a transaction object corresponding to a first paymenttransaction, wherein the transaction exchange platform comprises a firstgeographic region and a second geographic region different from thefirst geographic region. The computer-implemented method may determine,by the first microservice while processing the transaction object, thatthe processing of the transaction object requires use of a firstresource, for example, in response to retrieving a plurality oftransaction objects from the first streaming data platform and based ona determination that a workflow stage of the transaction object matchesa first workflow stage associated with a first microservice. The firstmicroservice may be associated with the first geographic region. Thecomputer-implemented method may acquire, by a first locking microserviceassociated with the first geographic region and based on a determinationthat the processing of the transaction object requires use of the firstresource, a lock for the first resource. The computer-implemented methodmay acquire the lock by receiving, by the first locking microservicefrom the first microservice, a request for a lock for the firstresource; transmitting, by the locking microservice to a distributedlock manager, an inquiry whether a lock exists for the first resourcebased on a determination that a lock does not exist for the firstresource in a local data structure; receiving, from the distributed lockmanager, a response indicating a lock does not exist for the firstresource; transmitting, by the locking microservice to the distributedlock manager and based on the response indicating that a lock does notexist for the first resource, the request for a lock for the firstresource; and receiving, by the locking microservice from thedistributed lock manager, the lock for the first resource. The lock maybe granted, for example, based on a consensus protocol indicating thatthe lock should be granted to the first microservice.

The computer-implemented method may determine, by a watchdogmicroservice, that processing of the transaction object has failed. Thecomputer-implemented method may cause a first microservice to repeatprocessing of the transaction object based on snapshot datacorresponding to the transaction object from prior to a start of theprocessing by the first microservice. The computer-implemented methodmay cause the first microservice to repeat processing of the transactionobject by re-generating, by a snapshot microservice, the transactionobject based on the snapshot data corresponding to the first transactionobject from a point prior to a failure of the processing of the firsttransaction object; returning the regenerated first transaction objectto a streaming data platform, wherein the workflow stage of theregenerated first transaction object is set to the first workflow stage;and re-acquiring, by the locking microservice, a lock for the firstresource. The computer-implemented method may process, by the firstmicroservice, the regenerated transaction object using the firstresource to generate an updated value of the first resource. Thecomputer-implemented method may transmit, by the locking microservice toa second locking microservice associated with a second streaming dataplatform associated with a geographic region that is different from ageographic region of the streaming data platform, a synchronizationsignal indicating the updated value for the first resource.

According to some aspects, a transaction exchange platform may comprisea streaming data platform, a plurality of microservices, at least oneprocessor, and memory. The plurality of microservices may comprise atleast a first microservice, a second microservice, a first lockingmicroservice, a second locking microservice, a watchdog microservice,and/or a snapshot microservice. The memory may store instructions that,when executed by the at least one processor, cause the transactionexchange platform to receive a transaction object corresponding to afirst payment transaction, wherein the transaction exchange platformcomprises a first geographic region and a second geographic regiondifferent from the first geographic region. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to determine, by the firstmicroservice while processing the transaction object, that theprocessing of the transaction object requires use of a first resource,for example, in response to retrieving a plurality of transactionobjects from the first streaming data platform and based on adetermination that a workflow stage of the transaction object matches afirst workflow stage associated with a first microservice. The firstmicroservice may be associated with the first geographic region. Thememory may store instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to acquire, by afirst locking microservice associated with the first geographic regionand based on a determination that the processing of the transactionobject requires use of the first resource, a lock for the firstresource. The memory may store instructions that, when executed by theat least one processor, cause the transaction exchange platform toacquire the lock by receiving, by the first locking microservice fromthe first microservice, a request for a lock for the first resource;transmitting, by the locking microservice to a distributed lock manager,an inquiry whether a lock exists for the first resource based on adetermination that a lock does not exist for the first resource in alocal data structure; receiving, from the distributed lock manager, aresponse indicating a lock does not exist for the first resource;transmitting, by the locking microservice to the distributed lockmanager and based on the response indicating that a lock does not existfor the first resource, the request for a lock for the first resource;and receiving, by the locking microservice from the distributed lockmanager, the lock for the first resource. The lock may be granted, forexample, based on a consensus protocol indicating that the lock shouldbe granted to the first microservice.

The memory may store instructions that, when executed by the at leastone processor, cause the transaction exchange platform to determine, bya watchdog microservice, that processing of the transaction object hasfailed. The memory may store instructions that, when executed by the atleast one processor, cause the transaction exchange platform to cause afirst microservice to repeat processing of the transaction object basedon snapshot data corresponding to the transaction object from prior to astart of the processing by the first microservice. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to cause the first microservice torepeat processing of the transaction object by re-generating, by asnapshot microservice, the transaction object based on the snapshot datacorresponding to the first transaction object from a point prior to afailure of the processing of the first transaction object; returning theregenerated first transaction object to a streaming data platform,wherein the workflow stage of the regenerated first transaction objectis set to the first workflow stage; and re-acquiring, by the lockingmicroservice, a lock for the first resource. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to process, by the first microservice,the regenerated transaction object using the first resource to generatean updated value of the first resource. The memory may storeinstructions that, when executed by the at least one processor, causethe transaction exchange platform to transmit, by the lockingmicroservice to a second locking microservice associated with a secondstreaming data platform associated with a geographic region that isdifferent from a geographic region of the streaming data platform, asynchronization signal indicating the updated value for the firstresource.

According to some aspects, one or more non-transitory computer readablemedia may comprise instructions that, when executed by at least oneprocessor, cause a transaction exchange platform to perform steps. Thosesteps may comprise receiving, by a transaction exchange platform, atransaction object corresponding to a first payment transaction, whereinthe transaction exchange platform comprises a first geographic regionand a second geographic region different from the first geographicregion; in response to retrieving a plurality of transaction objectsfrom the first streaming data platform and based on a determination thata workflow stage of the transaction object matches a first workflowstage associated with a first microservice, determining, by the firstmicroservice while processing the transaction object, that theprocessing of the transaction object requires use of a first resource,wherein the first microservice is associated with the first geographicregion; acquiring, by a first locking microservice associated with thefirst geographic region and based on a determination that the processingof the transaction object requires use of the first resource, a lock forthe first resource; determining, by a watchdog microservice, thatprocessing of the transaction object has failed; causing a firstmicroservice to repeat processing of the transaction object based onsnapshot data corresponding to the transaction object from prior to astart of the processing by the first microservice, wherein causing thefirst microservice to repeat processing of the transaction objectcomprises: re-generating, by a snapshot microservice, the transactionobject based on the snapshot data corresponding to the first transactionobject from a point prior to a failure of the processing of the firsttransaction object; returning the regenerated first transaction objectto a streaming data platform, wherein the workflow stage of theregenerated first transaction object is set to the first workflow stage;re-acquiring, by the locking microservice, a lock for the firstresource; and processing, by the first microservice, the regeneratedtransaction object using the first resource to generate an updated valueof the first resource.

Acquiring the lock for the first resource may include receiving, by thefirst locking microservice from the first microservice, a request for alock for the first resource; based on a determination that a lock doesnot exist for the first resource in a local data structure,transmitting, by the locking microservice to a distributed lock manager,an inquiry whether a lock exists for the first resource; receiving, fromthe distributed lock manager, a response indicating a lock does notexist for the first resource; transmitting, by the locking microserviceto the distributed lock manager and based on the response indicatingthat a lock does not exist for the first resource, the request for alock for the first resource; and receiving, by the locking microservicefrom the distributed lock manager, the lock for the first resource,wherein the lock is granted based on a consensus protocol indicatingthat the lock should be granted to the first microservice. The steps mayfurther comprise transmitting, by the first locking microservice, arequest to release the lock based on a determination that the firstmicroservice has completed processing of the transaction object usingthe first resource. The steps may also include transmitting, by thelocking microservice to a second locking microservice associated with asecond streaming data platform associated with a geographic region thatis different from a geographic region of the streaming data platform, asynchronization signal indicating the updated value for the firstresource. A determination to repeat processing of the transaction objectmay be based on a number of attempts at repeating processing of thefirst transaction being less than a threshold. The lock may not bereleased in response to a determination that processing of thetransaction object by the first microservice has failed.

As noted above, the present disclosure provides a locking microservicethat enables lock acquisition consensus across a geographicallydistributed system, with fast read/write access to corresponding valuedata stored in the region processing the transaction. The lockingmicroservice may leverage the consensus protocol only when acquiring alock on a key value and handles all other aspects of data access with alocal fast write forward system. This is an improvement over existingsystems since leveraging consensus protocol only when acquiring a lockon a key value, and handling all other aspects of data access with afast write forward system, guarantees idempotent transactions in asystem with data replicated across regions. By limiting the consensusprotocol interactions only to writing unique keys—which is done once pertransaction, the locking microservice described herein improvesperformance by storing metadata and/or application-related state detailsin the local cache system after the lock is acquired. This improves theperformance and reliability of the distributed locking mechanismdescribed herein. Moreover, performance may be further improved bysharding data across different consensus clusters and managing leaderand quorum placement in the region with the highest volume of traffic.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A computer-implemented method comprising:receiving, by a transaction exchange platform, a transaction objectcorresponding to a first payment transaction, wherein the transactionexchange platform comprises a first streaming data platform associatedwith a first geographic region and a second streaming data platformassociated with a second geographic region different from the firstgeographic region; in response to retrieving a plurality of transactionobjects from the first streaming data platform and based on adetermination that a workflow stage of the transaction object matches afirst workflow stage associated with a first microservice, determining,by the first microservice while processing the transaction object, thatthe processing of the transaction object requires use of a firstresource, wherein the first microservice is associated with the firstgeographic region; acquiring, by a first locking microservice associatedwith the first geographic region and based on a determination that theprocessing of the transaction object requires use of the first resource,a first lock for the first resource; determining, by a watchdogmicroservice, that processing of the transaction object has failed;releasing, by the watchdog microservice and based on a determinationthat processing of the transaction object using the first resource hasfailed, the first lock from the first resource; transferring, by thewatchdog microservice, processing of the first transaction object to thesecond geographic region; acquiring, by a second locking microserviceassociated with the second geographic region and based on adetermination that the processing of the transaction object requires useof the first resource, a second lock for the first resource; and inresponse to receiving the second lock, processing, by a secondmicroservice, the transaction object using the first resource togenerate an updated value of the first resource.
 2. Thecomputer-implemented method of claim 1, further comprising: in responseto receiving the first lock, processing, by the first microservice, thetransaction object using the first resource, wherein processing thetransaction object comprises updating a workflow stage associated withthe transaction object, wherein the updated workflow stage istransmitted to the second geographic region when the transaction objectis transferred.
 3. The computer-implemented method of claim 1, furthercomprising: updating a region associated with the first transactionobject to the second geographic region in response to transferring thetransaction object.
 4. The computer-implemented method of claim 1,wherein the determination that processing of the transaction objectusing the first resource has failed is based on a predetermined amountof time elapsing since the first lock was acquired.
 5. Thecomputer-implemented method of claim 1, wherein acquiring the first lockfor the first resource comprises: receiving, by the first lockingmicroservice from the first microservice, a request for a lock for thefirst resource; based on a determination that a lock does not exist forthe first resource in the local data structure, transmitting, by thelocking microservice to a distributed lock manager, an inquiry whether alock exists for the first resource; receiving, from the distributed lockmanager, a response indicating a lock does not exist for the firstresource; transmitting, by the locking microservice to the distributedlock manager and based on the response indicating that a lock does notexist for the first resource, the request for a lock for the firstresource; and receiving, by the locking microservice from thedistributed lock manager, the first lock for the first resource, whereinthe lock is granted based on a consensus protocol indicating that thefirst lock should be granted to the first microservice.
 6. Thecomputer-implemented method of claim 1, further comprising:transmitting, by the second locking microservice, a request to releasethe lock based on a determination that the second microservice hascompleted processing of the transaction object using the first resource.7. A transaction exchange platform comprising: at least one processor;and memory storing instructions that, when executed by the at least oneprocessor, cause the transaction exchange platform to: receive atransaction object corresponding to a first payment transaction, whereinthe transaction exchange platform comprises a first streaming dataplatform associated with a first geographic region and a secondstreaming data platform associated with a second geographic regiondifferent from the first geographic region; in response to retrieving aplurality of transaction objects from the first streaming data platformand based on a determination that a workflow stage of the transactionobject matches a first workflow stage associated with a firstmicroservice, determine, by the first microservice while processing thetransaction object, that the processing of the transaction objectrequires use of a first resource, wherein the first microservice isassociated with the first geographic region; acquire, by a first lockingmicroservice associated with the first geographic region and based on adetermination that the processing of the transaction object requires useof the first resource, a first lock for the first resource; determine,by a watchdog microservice, that processing of the transaction objecthas failed; release, by the watchdog microservice and based on adetermination that processing of the transaction object using the firstresource has failed, the first lock from the first resource; transfer,by the watchdog microservice, processing of the first transaction objectto the second geographic region; acquire, by a second lockingmicroservice associated with the second geographic region and based on adetermination that the processing of the transaction object requires useof the first resource, a second lock for the first resource; and inresponse to receiving the second lock, process, by a secondmicroservice, the transaction object using the first resource togenerate an updated value of the first resource.
 8. The transactionexchange platform of claim 7, wherein the instructions, when executed bythe at least one processor, cause the transaction exchange platform to:in response to receiving the first lock, process the transaction objectusing the first resource, wherein processing the transaction objectcomprises updating a workflow stage associated with the transactionobject, wherein the updated workflow stage is transmitted to the secondgeographic region when the transaction object is transferred.
 9. Thetransaction exchange platform of claim 7, wherein the instructions, whenexecuted by the at least one processor, cause the transaction exchangeplatform to: update a region associated with the first transactionobject to the second geographic region in response to transferring thetransaction object.
 10. The transaction exchange platform of claim 7,wherein the determination that processing of the transaction objectusing the first resource has failed is based on a predetermined amountof time elapsing since the first lock was acquired.
 11. The transactionexchange platform of claim 7, wherein the instructions, when executed bythe at least one processor, cause the transaction exchange platform to:receive, by the first locking microservice from the first microservice,a request for a lock for the first resource; based on a determinationthat a lock does not exist for the first resource in the local datastructure, transmit, by the locking microservice to a distributed lockmanager, an inquiry whether a lock exists for the first resource;receive, from the distributed lock manager, a response indicating a lockdoes not exist for the first resource; transmit, by the lockingmicroservice to the distributed lock manager and based on the responseindicating that a lock does not exist for the first resource, therequest for a lock for the first resource; and receive, by the lockingmicroservice from the distributed lock manager, the first lock for thefirst resource, wherein the lock is granted based on a consensusprotocol indicating that the first lock should be granted to the firstmicroservice.
 12. The transaction exchange platform of claim 7, whereinthe instructions, when executed by the at least one processor, cause thetransaction exchange platform to: transmit, by the second lockingmicroservice, a request to release the lock based on a determinationthat the second microservice has completed processing of the transactionobject using the first resource.
 13. One or more non-transitorycomputer-readable media comprising instructions that, when executed,cause a transaction exchange platform to: receive a transaction objectcorresponding to a first payment transaction, wherein the transactionexchange platform comprises a first streaming data platform associatedwith a first geographic region and a second streaming data platformassociated with a second geographic region different from the firstgeographic region; in response to retrieving a plurality of transactionobjects from the first streaming data platform and based on adetermination that a workflow stage of the transaction object matches afirst workflow stage associated with a first microservice, determine, bythe first microservice while processing the transaction object, that theprocessing of the transaction object requires use of a first resource,wherein the first microservice is associated with the first geographicregion; acquire, by a first locking microservice associated with thefirst geographic region and based on a determination that the processingof the transaction object requires use of the first resource, a firstlock for the first resource; determine, by a watchdog microservice, thatprocessing of the transaction object has failed; release, by thewatchdog microservice and based on a determination that processing ofthe transaction object using the first resource has failed, the firstlock from the first resource; transfer, by the watchdog microservice,processing of the first transaction object to the second geographicregion; acquire, by a second locking microservice associated with thesecond geographic region and based on a determination that theprocessing of the transaction object requires use of the first resource,a second lock for the first resource; and in response to receiving thesecond lock, process, by a second microservice, the transaction objectusing the first resource to generate an updated value of the firstresource.
 14. The one or more non-transitory computer-readable media ofclaim 13, wherein the instructions, when executed, cause the transactionexchange platform to: in response to receiving the first lock, processthe transaction object using the first resource, wherein processing thetransaction object comprises updating a workflow stage associated withthe transaction object, wherein the updated workflow stage istransmitted to the second geographic region when the transaction objectis transferred.
 15. The one or more non-transitory computer-readablemedia of claim 13, wherein the instructions, when executed, cause thetransaction exchange platform to: update a region associated with thefirst transaction object to the second geographic region in response totransferring the transaction object.
 16. The one or more non-transitorycomputer-readable media of claim 13, wherein the determination thatprocessing of the transaction object using the first resource has failedis based on a predetermined amount of time elapsing since the first lockwas acquired.
 17. The one or more non-transitory computer-readable mediaof claim 13, wherein the instructions, when executed, cause thetransaction exchange platform to: receive, by the first lockingmicroservice from the first microservice, a request for a lock for thefirst resource; based on a determination that a lock does not exist forthe first resource in the local data structure, transmit, by the lockingmicroservice to a distributed lock manager, an inquiry whether a lockexists for the first resource; receive, from the distributed lockmanager, a response indicating a lock does not exist for the firstresource; transmit, by the locking microservice to the distributed lockmanager and based on the response indicating that a lock does not existfor the first resource, the request for a lock for the first resource;and receive, by the locking microservice from the distributed lockmanager, the first lock for the first resource, wherein the lock isgranted based on a consensus protocol indicating that the first lockshould be granted to the first microservice.
 18. The one or morenon-transitory computer-readable media of claim 13, wherein theinstructions, when executed, cause the transaction exchange platform to:transmit, by the second locking microservice, a request to release thelock based on a determination that the second microservice has completedprocessing of the transaction object using the first resource.